You are here: NI Home > Support > Product Reference > Manuals > LabVIEW 8.5 Help

Configuration management is the process of controlling changes and ensuring they are reviewed before they are made. A central focus of development models is to convert software development from a chaotic, unplanned activity to a controlled process. These models improve software development by establishing specific, measurable goals at each stage of development.

Regardless of how well development proceeds, changes that occur later in the process need to be implemented. For example, customers often introduce new requirements in the design stage, or performance problems discovered during development prompt a reevaluation of the design. You also might need to rewrite a section of code to correct a problem found in testing. Changes can affect any component of the project from the requirements and specification to the design, code, and tests. If you do not make these changes carefully, you can introduce new problems that can delay development or degrade quality.

Source Control

After you set the project quality requirements, develop a process to deal with changes. This process is important for projects with multiple developers. As developers work on VIs, they need a method to collect and share their work. A simple method to deal with this is to establish a central source repository. If all the development computers are on the network, you can create a shared location that serves as a central source for development. When developers need to modify files, they can retrieve the files from this location. When developers complete their changes, they can return the files to this location.

Common files and areas of overlap introduce the potential for accidental loss of work. If two developers decide to work on the same VI at the same time, only one developer can work on the master copy. The other developer must compare the VIs to determine the differences and incorporate the changes into a new version. Avoid this situation by ensuring good communication among the developers. If each developer notifies the others when he needs to work on a specific VI, the others know not to work on that VI.

Source control is a good solution to the problem of sharing VIs and controlling access to avoid accidental loss of data. Source control makes it easy to set up shared software projects and to retrieve the latest files from a server. After you create a source control project, you can check out a file for development. Checking out a file marks it with your name so other developers know you are working on the file. If you want to modify a file, you can check out the file from source control, make changes, test the changes, and check the file back into source control. After you check in the file, the latest version is available to the development team. Another developer can check out the file to make further modifications.

Note  Source control integration in LabVIEW is available only with the Professional Development System.

You must select, install, and configure a source control provider in order to use source control in a software project. In addition to maintaining source code, a source control provider can manage other aspects of a software project. For example, you can use a source control provider to track changes made to feature specifications and other documents. You can control access to these documents and share them as needed. You also can access older versions of the files in source control.

Refer to the KnowledgeBase for the most current list of third-party source control providers that work with LabVIEW.

Source management of all software project-related files is extremely important for developing quality software. Source management is a requirement for certification under existing quality standards, such as ISO 9000.

Retrieving Old Versions of Files

Sometimes you might need to retrieve an old version of a file. For example, you might change a file, check it in, and then realize you need to undo the change. You also might want to send a previous version of the software to a customer while you continue development. If the customer reports a problem, you can access a copy of the previous version of the software.

One way to access an old version of a file or project is to keep backup copies. However, unless you back up the file after every change, you do not have access to every version.

Source control provides a way to check in new versions of a file and access previous versions. Depending on how you configure the source control provider, the tools can store multiple versions of a file.

Tracking Changes

If you are managing a software project, it is important to monitor changes and track progress toward specific milestone objectives. You can use this information to determine problem areas of a project by identifying which components required many changes.

Source control providers maintain a log of all changes made to files and projects. When checking in a file, the provider prompts the developer to write a summary of the changes made. The provider adds this summary information to the log for that file.

You can view the history information for a file or for the system and generate reports that contain the summary information.

In addition, if you back up files at specific checkpoints, you can compare the latest version of a file with another version to verify changes.

Change Control

Large software projects can require a formal process for evaluation and approval each time a developer asks to make changes. A formal process can be too restrictive, so be selective when selecting the control mechanisms you introduce into the system.

Deal cautiously with changes to specific components, such as documents related to user requirements, because they generally are worked out through several iterations with the customer. In this case, the word “customer” is used in a general sense. You can be the customer, other departments in a company can be the customer, or you can develop the software under contract for a third party. When you are the customer, adjusting requirements as you move through the specification and even the design stage is much easier. If you are developing for someone else, changing requirements is more difficult.

Source control gives you a degree of control when making changes. You can track all changes, and you can configure a source control provider to maintain previous versions so you can undo changes if necessary. Some source control providers give you more options for controlling software change. For example, with Microsoft Visual SourceSafe, IBM Rational ClearCase, or Perforce, you can control access to files so some users have access to specific files but others do not. You also can specify that anyone can retrieve files but only certain users can make modifications.

With this kind of access control, consider limiting change privileges for requirement documents to specific team members. You also can control access so a user has privileges to modify a file only with the approval of the change request.

The amount of control you apply varies throughout the development process. In the early stages of the project, before formal evaluation of the requirements, you do not need to strictly restrict change access to files nor do you need to follow formal change request processes. After the requirements are approved, however, you can institute stronger controls. Apply the same concept of varying the level of control to specifications, test plans, and code before and after completing a project phase.