4.2 Comparison of key functionality

 < Day Day Up > 



This section outlines some functionality important in either PDM or SCM (or both). We focus on the differences between PDM and SCM.

Functionality closely related to PDM or SCM only is not treated here. Separate tools or modules within the tools, such as requirement management (RM) tools or modules, manage these.

4.2.1 Version management

Version models in PDM differ from those in SCM.

In PDM systems, the versions of a business item are denoted revisions. Revisions are organized in a flat structure (only one main branch, denoted A and B in Figure 4.3), as compared with the hierarchical structure in SCM, which allows branching and merging. A business item represents and carries metadata for both products and documents. This metadata, shown in Figure 4.3, is denoted attributes. Attributes are used frequently in PDM systems and are visible to the users. Only major changes of a business item are tracked by revisions (i.e., revised from revision A to B—see Figure 4.3), and this transition is performed manually by the user. The different revisions of a business item are connected by means of a relationship. The revision-of relationship is depicted in the figure, but a PDM system can contain many other relationships, which may have one or more attributes.

click to expand
Figure 4.3: Version management in PDM.

To change a released business item or its associated data items (files), a new revision of the business item must be created. When the business item is approved, its new revision is frozen. If data items are associated with the business item, it is most often the data item that is changed. While the data item is changed, it may be checked in and out several times without creating a new revision. To manage the sequence of data items (shown as 1 and 2 in Figure 4.3), versions are used internally in the PDM system. These versions are normally not visible to the user.

Versions in SCM form a hierarchical structure (see Figure 4.4), in which two versions of a file can be developed simultaneously in branches, which may be merged together again if needed. Each time a file is checked out and in, a new version is created. This corresponds to a version in PDM. In SCM, however, versions are visible to the user and are used frequently. A version of a file can be marked with attributes, but is rarely used and normally not visible to the users. Later, a baseline is created by manually selecting the versions to be included in the configuration.

click to expand
Figure 4.4: Version management in SCM.

These versions are then marked using a special attribute often called a tag or label. Labeled versions thus almost correspond to revisions in PDM.

In the following list, the concepts in Figure 4.3 and Figure 4.4 are shown in italic type. The following list shows the similarities of version management in PDM and in SCM and the differences between them:

  • PDM manages objects. SCM manages files and directories.

  • PDMuses revisions for major changes. SCMuses versions for all changes.

  • SCM has branches and supports merge functionality. PDM does not.

  • In SCM, several people can work on the same file at the same time using the branch facility, which is not possible in PDM.

  • Both SCM and PDM tools have attributes. SCM has a special attribute called label, which is frequently used. General (user-defined) attributes are rarely used in SCM due to restricted usability. PDM strongly supports customized attributes through its data model.

  • PDM has relationships, SCM does not (apart from the revision-of relationship implementing historical versioning).

  • A relationship may have attributes in PDM but not in SCM.

4.2.2 Product structure management

Product structure management is a basic and fundamental functionality in a PDM system, described in detail in Section 2.2.3. The PDM system describes a configuration by arranging the parts in a structure consisting of different products or parts connected by relationships. The product structure commonly follows the same pattern as the structure of the physical product. Different kinds of structures can be defined in a PDM system by specifying different views (e.g., the view describing the parts by their business items connected by relationships). A database model supports the building of product structures. Different views of a product structure can also be used to support different roles (e.g., the manufacturing engineer needs to see the components of a product to enable him to assemble it for delivery to the customer).

SCM tools do not explicitly address and support product structures. Only rudimentary support, in the form of directories in a file system, is available for use in building a hierarchical structure, and SCM tools provide support for managing these structures during the development phase. It is not possible to see directly the relationship between these structures and the structures of the executable software. This relationship is not visible, even when some of the advanced SCM tools use relational databases for storing product metadata. Metadata is used to describe the states of CIs, which are not complex objects or components but only files or sets of files.

4.2.3 Build management

The build process is very specific to software products. It is both computation and automation intensive, but short in comparison with other phases or with the process of building hardware products. The build process includes two central types of transformations. First, the source code, legible to humans, is transformed to a binary form (also designated as machine code or executable code). Second, the product structure itself is changed. Typically, a new directory structure including the newly created binary files will be created. The transformation from source code to binary code is performed by compilers. Transformation of the structure is a part of build management.

Build is essential in SCM and supported as described briefly in Section 3.2.4. Build is in no way supported in PDM for software.

4.2.4 Change management

The basic principles of change management in PDM and SCM are similar. In PDM, add-on modules support change management. In SCM, there are specific change management tools integrated with the SCM system. Because of the nature of the software, the change process and the traceability (see Section 3.2.8) are better integrated with change management. For hardware products, the change process itself is usually outside the scope of the change management tools. The changes are either performed outside the computer system (if a physical change) or with tools (such as CAD/CAM), whose management objects (drawings) are not manageable outside these tools. This has the consequence of change management (in PDM systems) becoming a way of documenting the process, which is very similar to document management. For software producers, whose artifacts are always stored in a computer, it is easier to achieve a tight integration between the change process itself and change management. For example, a developer can access files to be modified directly from the change management tools, or a new product version can be built automatically from a particular product version or baseline with added changes. This type of support is often available in SCM tools.

4.2.5 Release management

Simple support for release management is available in SCM for pure software products (e.g., packaging of the executables, related documents, and installation program). In PDM, the support for release management is strong. The manufacturing engineer uses the BOM (the list of all parts included in the final product, as described in Section 2.2.3) to assemble the final product. The BOM is a part of the product structure. The package sent to the customer is a component in the product structure with relationships to the constituent artifacts.

4.2.6 Workflow and process management

Workflows and processes can be defined and executed in PDM systems. All processes can be changed and adapted to specific projects. Some SCM tools incorporate similar functionality or provide it using tools tightly integrated within the tool suite. In most SCM systems, however, there are only triggers, which can execute scripts written by the users. This is support of little value, as the result is a mess of scripts that are difficult to survey and maintain.

4.2.7 Document management

PDM has built-in document management facilities such as query, viewing, and access control, which are not available in SCM. However, as developers prefer to work in an integrated development environment with easy access to all of the artifacts being developed or used in the development process, there is a trend to store more and more documents within SCM, despite its lack of query functions and other document management capabilities.

4.2.8 Concurrent development

Both PDM and SCM provide shared databases/repositories and locking functions to prevent simultaneous updates. SCM also provides workspace management together with branch and merge, which makes it possible for developers to work concurrently on the same file (see Figure 4.4). The support of merge also makes it possible to provide optimistic check out instead of locking, as described for SCM in Section 3.2.6.

4.2.9 CM and selection management

There are usually many versions of the same file stored in an SCM system. The SCM tool provides support for selection of the correct version of each file. This is important both when retrieving versions for use in workspace and when the product is to be built. There is no functionality in PDM comparable with the selection function in SCM. Many PDM systems support configuration effectivity, which is a time or revision limitation (see Section 2.5.1). However, this is not selection management but more logical versioning, as described in Section 4.1.3.

4.2.10 Workspace management

In an SCM system, the user checks out all of the files to be changed and stores these in his or her workspace. The SCM system registers all files checked out, the version checked out, by whom, and in which workspace the copy is stored. If many users check out the same file (and possible the same version), these check outs are coordinated under the control of the tool in accordance with the synchronization model used. Each user can set up and change the definition (selection) of the files (versions) that are to be checked out to the workspace.

Workspace management in this form is not provided in PDM systems. PDM systems have work locations (which are private file locations), with one location defined per user (described in Section 2.4). In PDM, the user checks out one file at a time and updates it. Locking prevents more than one user from checking out the same version of the same file simultaneously (it is usually only the latest version that is checked out). When checking out the file, it will be saved in a private work location, which must be set up by the system administrator. The user need not know the physical situation of the location and has no authority to change the location.

4.2.11 Role definitions

While the role concept is an important feature of PDM tools and is integrated with the support for workflow and process management, the support provided by SCM tools is more varied. Many SCM tools distinguish users only by the user identity. A few SCM tools support roles and access rules.



 < Day Day Up > 



Implementing and Integraing Product Data Management and Software Configuration[... ]ement
Implementing and Integrating Product Data Management and Software Configuration Management (Artech House Computing Library)
ISBN: 1580534988
EAN: 2147483647
Year: 2006
Pages: 122

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net