Implementing and Integrating Product Data Management and Software Configuration Management (Artech House Computing Library)

In Chapter 1, we depicted a generic life cycle process model. This model is general and valid for both hardware and software development, although different subactivities are included and different priorities are allocated. In this section, we will describe the life cycle processes of both hardware and software products in more detail, to be able to determine if there are different requirements and, if so, what these are. We will focus on the phase with the most activities, the development process, and identify the PDMand SCM-related requirements to provide support for the development activities.

5.1.1 Hardware products

In this context, a hardware product is a product containing hardware only (i.e., no software components). Most of the hardware product development consists of different descriptions of the product in many different documents (e.g., drawings and manufacturing specifications, which describe the product itself and the components included in it). The most important PDMrelated requirement for hardware development is the ability to manage these documents and the product structures.

A more detailed description of the most common requirements related to information assets (documentation and other type of data) that are created, changed, and used is given next.

• Customer demands are translated into system requirements. These requirements are combined with internal requirements from stakeholders, such as production factors (e.g., low production costs, compatibility with existing production processes, and low assembly costs) and maintenance requirements. It must be possible for requirements engineers to access all information needed to identify the requirements for the particular products and to specify the requirements that will be used later in the development process.

• The mechanical and electronics designers need to manage the documents, which they create using CAD/CAM and other tools or directly by means of a PDM system.

• The developers must be able to version control their parts (components in the product structure) and related documents. Normally, concurrent work on the same document or part is not allowed, but locking mechanism is used. However, some CAD systems allow developers to divide a part into zones, each zone being checked out separately, instead of the part as a whole. The manufacturing and purchasing departments must be able to purchase and manufacture components, assemble the product, and deliver it to a customer. They need a BOM to prepare forecasts to perform purchasing and production line planning, tool ordering, and assembly. Drawings and other documents are used to specify how to build manufacturing tools and to manufacture parts.

• The documents and the product structure must be available for writers of user manuals. They need to know the product’s functionality, design, requirements met, and so on.

• Information about the product must be available to other stakeholders, such as advertising and sales people.

• All information assets must be stored in archives. All components and their documents must be available in up-to-date versions for maintenance purposes and for future releases of the product.

• To establish a baseline or a release, it is necessary to freeze all relevant products and documents. Beyond the baseline point, formal change management is required to manage changes. In hardware development, late changes can be very expensive, due to the probable costs of redesigning manufacturing tools and the production process.

Let us study the development process from Chapter 1 to determine in which parts of the process each information asset is actually generated and used. The process contains five steps, as shown in Figure 5.1. It begins with the collection and analysis of detailed requirements and a conceptual development phase, in which the needs of the market are investigated and the overall requirements defined, followed by the generation of product concepts. In the system-level design phase, the architecture of the product is decided. This includes the identification of subsystems, components, and the interfaces between them. The design of the components is further developed during the detailed design phase. The testing and refinement phase includes the building of product prototypes used to test both the product and the production system. During the production ramp up, the production system is used for serial production of the product, beginning at a low rate and then increasing to full production capacity. The figure also shows the types of information used to describe the product. The bars show approximately in which of the phases information evolves and in which it is used.

Figure 5.1: Hardware development process and information usage.

In the early phases, the product is described by functions and possibly also in terms of geometric layouts. The architecture is not an information object in itself, but is presented as geometric layouts, system structures, and preliminary product (component) structures. During the detail design, the product structures become more detailed, components are identified and designed, work on the prototype development is begun, and documents related to the manufacturing process and tooling are prepared. In the final stage, preparations for production are concluded, and the final release of the product documentation is prepared. From Figure 5.1, we can also see that most of the information is used during the entire process.

5.1.2 Software products

During software product development, it is most important for developers to be able to manage documents and a huge amount of source code. An SCM tool is usually used to manage software structures and the relationships between components, which mostly exist in source code form. Documents are most often stored together with the source code in the SCM tool. This product category contains no hardware of any kind, and there is no apparent need for a PDM system.

The requirements related to the management of information assets, created, changed, and used in the development of software are summarized next:

• The customer demands are translated to system requirements, in the same way as for hardware products. As one of the main characteristics of software is that it is easy to change, many requirements address the improvement of existing products, which is a part of the maintenance process.

• The system designers prepare overall and subsequently detailed design documents. These documents may include textual information but also other types of information (e.g., diagrams or formal specifications) that can be used for the generation of templates for source code.

• During the development phase, developers use different tools for writing and generating source code and for building executable code. Software systems are built from large numbers of source code files. To concurrently develop such systems, software development needs a support for detailed version control (using revisions, branches, and merges). There are many more versions of software files and databases than there are of hardware.

• A baseline, with frozen documentation and source code files, must be established. As it is relatively easy to build executables from source code, they are usually not versioned in the same way as the source code because they can be reproduced. ^[1] When the baseline is verified, the developer may release the product for further testing or delivery to the customer.

• To deliver the product to a customer, the manufacturing department must be able to produce product packages suitable for delivery (e.g., the product can be burned on media or published on the Web). The manufacturer must also retrieve relevant documents.

• For marketing and sales, the product information (e.g., brochures, release notes, list of known problems, and product descriptions) must be available for communication to customers.

• All information (documentation, source code, and deliverables) must be stored in archives. All components and their documents must be available in the right revisions for maintenance purposes and for future releases of the product.

• Technically, changes are easy to introduce in software products, which enables a more flexible development process. However, if the change process is not under strict control, enormous overhead in the time and costs can appear. An uncontrolled change process is one of the largest problems in software development. For this reason, when the software product is released, or even when the first baseline of software is created, the formal change management must be performed.

The software development process [1] follows a schema similar to that for hardware development. During the requirements analysis phase, the system’s services, constraints, and goals are established in the system specification. In the next phase, software design, an overall system architecture is established in which the fundamental software systems abstractions and their relationships are identified and described. The implementation phase comprises formalization of the design by creating source code or using preexisting code or packages. The implemented units of software are created and tested. In the integration phase, the software units are integrated in a software system. The integration phase corresponds to the production of hardware. During the test phase, the system is verified and validated. Finally, the system is released and delivered to a customer.

The phases of the development process are shown in Figure 5.2. This sequential model is a well-known waterfall model. We can, however, see that the information flow is not sequential, but rather follows a V shape. Indeed, there is a development model called the V model [2], which provides support for exchanging information between the different phases of the process. The V model indicates the reuse of information. The requirements specification is used in the later phases (e.g., during the test and release process). The test process itself is divided into a validation phase, in which the implemented functions are tested, and a verification phase, in which the product is tested with respect to the specified requirements. ^[2] The requirements may be modified during the design phase and even later during the implementation. Overall design documents specify the product overall structure, main classes and objects, functions, and interfaces between different parts. This information is frequently used during the specification of the detailed design, which includes descriptions of objects and functions to be implemented. The detailed design, created in the next phase and most likely modified during the implementation phase, is used later in the test (validation) phase. The source code created in the implementation phase is later used when building the product and in the test (validation) phase for review and debugging purposes. Finally, the executable code, which is compiled from the source code and different libraries in binary form, is used during the test and delivered to the customer. Project management plays the same role as for hardware products. An efficient and accurate project management is of as great importance as change management. The need for a tight integration of information through the entire process is similar to that for hardware products.

Figure 5.2: Software design process and information usage.

5.1.3 Remarks

Analyzing these hardware and software processes, we can derive the following conclusions:

• The development processes for hardware and software products are similar, but the terminology differs, and the activities and type of information managed may be very different.

• In both cases, it was shown that information integration during the process is very important. Most of the information is used and often updated during the entire process.

• Neither PDM nor SCM provide full support for the whole development process. An indicative example is requirements management and its relation to implementation and test. One of the main functions of PDM and SCM is to assure traceability, and yet these tools provide only rudimentary traceability from implementation or test to the requirements. An SCM tool often can include CRs and connect them to changes made in the source code, but how the relations between CRs and requirements are obtained is not clear. Similarly, with PDM, it is not possible to trace which CR is related to a change implemented in a CAD/CAM drawing. To provide full support, other tools are needed and even then a problem with their interoperability remains.

• Because of the importance of information integration, it is necessary to integrate the different tools used in the entire development environment. This is not only so for PDM or SCM tools, but is also the case for other tools used in the process.

In the analysis, we have focused on the development process (and to a degree on maintenance), not on the entire product life cycle. The development phase in which there is the largest overlap of SCM- and PDMrelated functions is the most complex. The results from the analysis can be extended to the entire PLC.

^[1]Automatic reproduction of executables is often a cause of many problems, as it is based on the principle that the executables can be reproduced in exactly the same way each time. While it is easy to identify source code used to build executables, it is almost impossible to reproduce the entire context in which the executables are created. For this reason, more sophisticated SCM tools are able to keep the executables under version control.

^[2]Validation and verification are terms that can be easily confused, although there is a clear distinction between them. Verification is a process that checks if the system meets its specified functional and nonfunctional requirements. A validation process should ensure that the system meets the customer’s expectation. Or, as expressively described by Boehm [3]:

• Validation: Are we building the right product?

• Verification: Are we building the product right?