Sample SCLM development cycle

Your typical daily operations using SCLM might flow like this: edit (SCLM editor), compile (Build), and test, repeating this cycle until testing is complete, and then promote. After the promote is performed, you or other developers can use the SCLM editor to automatically draw members down to a development group for modification.

The following list includes steps that you might perform in the development cycle of a software component or any type of data that is under SCLM control. Figure 1 illustrates the project flow of the following steps. The hierarchy used for this example is shown in Figure 1.

The developer draws down a source member from group RELEASE to group DEV1 and modifies it. The data at group RELEASE is the current release of the project. Changes are now being made for the next release. When the developer has made the modifications to the member, SCLM parses the member and registers it with SCLM. The successful registering of the update makes this member available for use by other SCLM functions.
The Build function is initiated against an architecture definition that includes this parsed and stored source member. This build creates object modules reflecting the changes that were made to the source member. The source, architecture definition, and object module members used here have been given the same member names. Thus, you can easily see how these members are related, although their types are different. These naming conventions, however, are not required by SCLM.
If the Build function does not complete successfully because of errors in the modified members, you must use the SCLM editor again to correct the errors, and try to build again.
The developer can now test the effect the changes have made to the application.
The developer then moves all the changed data to the group TEST by invoking PROMOTE using the same architecture definition that was previously built. The data changes are now available to all developers because they have reached a common group. If any changes in data made by the developer conflict with changes other developers are making in their development groups, these changes are found when the other developers build their changes at their development group.
Alternately, the person appointed as SCLM project manager can do the promote. The SCLM project manager is the person who has UPDATE authority to TEST and promote changes to this group. The SCLM project manager can guarantee all changes promoted to the group TEST have been unit tested (because the project manager can control the promotes).
When all changes scheduled for the next release have been promoted to the group TEST, testing the application can occur at this group while other programmers are still developing software in the development groups.
Finally, after system testing is complete in the TEST group, the new release of the project can be promoted to the RELEASE group.

Figure 1. Development Cycle

This flowchart shows how processes hang together. The first two processes are within the SCLM Edit framework. The first process is MODIFY OR CREATE MEMBER. This flows to PARSE AND STORE. If the PARSE AND STORE fails, the flow returns to MODIFY OR CREATE MEMBER. If it succeeds, the process moves to BUILD, which on success moves to TEST, which on success moves to PROMOTE. If the PROMOTE succeeds, then the changes are released to the application or production. Any failure in BUILD, TEST, or PROMOTE returns to MODIFY OR CREATE MEMBER. A successful PROMOTE can also lead to a repeat at the next layer of hierarchy, either as a new PROMOTE, or a new BUILD.