Optimizing Your SAS Performance with Grid Computing



Can Change Control be Easy as a Right Mouse Click?

Sy Truong, Meta-Xceed, Inc., Milpitas, CA

Rory DeShano, M.A., MedImmune, Inc., Gaithersburg, MD

Abstract

CHANGE CONTROL FUNCTIONS AS THE FUNDAMENTAL PROCESS FOR QUALITY CONTROL AND IS THE FOUNDATION FOR VALIDATION. THIS IS STANDARD PROCEDURE FOR SOFTWARE DEVELOPMENT BUT IS LACKING IN THE DEVELOPMENT OF ANALYSIS WHEN PROGRAMMING IN SAS. THE UNSTRUCTURED ADHOC NATURE OF DISCOVERY DURING ANALYZING DATA AND REPORTING CREATE CHALLENGES FROM THE PERSPECTIVE OF CHANGE CONTROL AND VALIDATION. HOWEVER, IT IS THIS DATA DRIVEN DYNAMIC PROGRAMMING ENVIRONMENT THAT REQUIRES THE RIGORS OF CHANGE CONTROL TO ENSURE THE INTEGRITY OF THE RESULTS. THIS PAPER EXPLORES PROCESSES AND TECHNIQUES USED TO MANAGE CHANGE CONTROL OF SAS PROGRAMS AND THE OUTPUT THEY PRODUCE WITHIN THE PROCESS OF DEVELOPMENT AND VALIDATION. SOME OF THE EXAMPLES IT WILL COVER INCLUDE:

• Version Control – Backward compatibility issues with older versions of SAS programs and output

• Understanding Differences – Comparing differences between versions of programs and output

• Noted Changes – Capture metadata or information describing the meaning or the context of the changes

• Validation Process – Managing changes from requirements through the testing of all programs

This paper will demonstrate the challenges faced with managing change control of SAS programs in a regulated industry. In the recent history of computing, the use of the mouse and its right mouse click contextual menu has made it easier to access information upon objects within its graphical user interface. This approach is used to simplify the process of managing change control of SAS programs.

Version Control

**************************************************************************************************************************************;

In this section, we will start describing the importance of versioning SAS programs since it is just ASCII files that can get deleted or corrupted. Other ideas include:

• Versioning of SAS Programs – Making backups without the cumbersome check in-checkout process.

• Versioning SAS Output – Extending into RTF, DOC, PDF and other SAS Output

**************************************************************************************************************************************;

Version control plays an essential role in any SAS programming environment. Not only does it assists one in keeping track of the life cycle of the program, but it can supply a quick reference point for any additional modifications one may have to make on an existing program. However, the life cycle of a SAS program or any other document is only useful if the proper life cycle information is captured. This would include, but is not limited to, programmers name, date, time and any relevant comments defining the program characteristics and/or any modifications to these characteristics. This poses some fundamental questions:

1. is there a software product that allows one to version their programs

2. without constantly checking them in and out

3. adequately compares differences form one version to the next

4. allow one to roll old version forward

5. enable one the ability to add notes quickly and efficiently and generates swift reports on the life cycle of any given program

The following example steps describe an approach that addresses some of these questions.

Step 1: Version SAS Programs – The user would right mouse click on a SAS program with a file extension of (.sas). A pop-up menu is presented with selections to perform backups or review the history. This is similar to submitting a SAS program in batch mode so it is similar to the workflow of the user.

[pic]

Step 2: Version SAS output– Similar to performing backups to SAS programs, a version of the SAS output can also be accomplished through the right mouse click. The difference being that the file can be a Word document with extension of either (.rtf or .doc), or Excel (.xls), or PDF (.pdf).

[pic]

Step 3: Add comments to versions – The file being versioned can retain meaning if the comments can be added explaining the reason for the version. This can be accomplished by adding notes which acts as metadata so that the history has contextual meaning for each version.

[pic]

Understanding Differences

*******************************************************************************************;

ONCE PROGRAMS ARE VERSIONED, WE CAN THEREFORE COMPARE DIFFERENCES WITH OLDER VERSION. THE USER CAN VIEW OLD VERSIONS AND COMPARISONS CAN HIGHLIGHT DIFFERENCES.

Noted Changes

Changes to program have more contextual meaning than just the text changes. The metadata associated with the changes referred to as “Notes” are important in describing what has changed. This section will describe the importance of collecting this metadata and how it is practically implemented

********************************************************************************************************;

The steps taken during the versioning of the program can help you better understanding the history of the program. Some of the information captured that contributes to the historical knowledge base includes the following.

|Key Advantage |Description |

|Notes |As mentioned in step 3 above, adding notes pertaining to the version adds key |

| |information that explains the significance to the backup. This can explains things |

| |such as important algorithm or key logic changes in the program or file. |

|Program Name |The program name is used to identify this file as compared to other programs being |

| |versioned. |

|User Name and Date Time |The user that is logged onto the system is captured along with the date time stamp of |

| |the version. |

|File Contents |The program code or the output file contents are then captured in. |

This information captured will provide key information towards understanding the complete picture of the history of the file. Besides understanding information pertaining to each version, understanding the difference among the version is also important. This will help determine the correct version to roll back to in the event that the current version is corrupted. The following steps are taken to see the differences.

Step 1: View the HIstory – The user would right mouse click on the program and select the history option from windows explorer.

[pic]

Step 2: Select two versions – In order to compare the difference, the user must select two different versions within the history. It is common that the latest version is then compared with one of the last production release of a program.

[pic]

Step 3: Compare – A comparison is made by clicking on the compare option. This will then perform a comparisons with differences highlighted. The left column within the comparison highlights in horizontal bars to indicate the area in the file that contains differences.

[pic]

If you were to scroll down to the view, the actual differences between the two files will be highlighted in color to descript the differences.

[pic]

This makes it much easier to quickly see the differences to determine the exact version that is the correct version.

Validation Process

********************************************************************************************;

WE CAN SHOW A SCENARIO WHERE WE CAN GO THROUGH A VALIDATION PROCESS OF A SAS PROGRAM OR MACRO. WE CAN THEREFORE HIGHLIGHT THE SIGNIFICANCE OF VERSION CONTROL IN THIS PROCESS AND HOW IT WOULD HELP IN THE EVENT OF UPGRADING A PROGRAM TO A PRODUCTION STATE.

********************************************************************************************;

The validation process for SAS programs and output can be a resource intensive an elaborate set of procedures. There are many considerations but it is important to stay close to the work flow of the SAS programmer while keeping to the goal of developing accurate programs which produce output with integrity. Some of the components that go into validation include:

• Risk Assessment – An evaluation of the impact the program has on data, output and other resources involved in the project.

• Independent Review – A separate programmer would develop another script in attempt to verify the same output.

• Visual Inspection – An independent reviewer would do a complete or partial visual inspection of output, program and log.

The underlining assumption is that one needs some type of documentation that accompanies their validation efforts. This section will demonstrate the process of validate a SAS program while maintaining also capturing the documentation.

Below is an example of the steps one could take in this process:

Step 3: Initial Version – This process would begin with the creation on a SAS program and tracking the program’s life cycle (i.e., V - Version + Notes). A comment or notes is kept to document and explain the significance of this step.

[pic]

Step 2: Locking For validation – Once the program is ready for validation one would lock down the program so no additional changes could occur during the validation process (i.e., V – Lock for Validation). This will help in change control since it will mark the beginning of the validation state with no additional changes to the program logic.

[pic]

Step 3: Document testing and set to production – Validation programming would take place at this step. In this instance we used independent programming to perform testing and document the findings pertaining to this program. Since no errors were found we utilized the “Production + Unlock” function. Note that this function only appears once a program has been locked down for validation.

[pic]

The above section integrates the work flow of the SAS programmer since the user can right mouse click on the program within Windows explorer to perform these tasks. It automatically stores the information centrally while capturing the user name and date time of the tester and programmer. This information is later used to generate documentation.

reports and documentation

THE REPORTING OF WHAT HAS BEEN VERSIONED CAN BE USED AS DOCUMENTATION WHEN COMMUNICATING THE DEVELOPMENT PROCESS TO COLLABORATORS. IT IS ALSO USEFUL DOCUMENTATION IN THE VALIDATION PROCESS. THIS SECTION WILL DISCUSS THE VALUE OF DOCUMENTING WHAT HAS BEEN CHANGED.

Conclusion

IN THE WORLD OF …

References

SAS AND ALL OTHER SAS INSTITUTE INC. PRODUCT OR SERVICE NAMES ARE REGISTERED TRADEMARKS OR TRADEMARKS OF SAS INSTITUTE INC. IN THE USA AND OTHER COUNTRIES. ® INDICATES USA REGISTRATION.

Statmark, Clustreon and other MXI (Meta-Xceed, Inc.) product names are registered trademarks of Meta-Xceed, Inc. in the USA.

Other brand and product names are registered trademarks or trademarks of their respective companies.

About the author

SY TRUONG IS PRESIDENT OF MXI (META-XCEED, INC.) THEY MAY BE CONTACTED AT:

Sy Truong

1751 McCarthy Blvd.

Milpitas, CA 95035

(408) 955-9333

sy.truong@meta-

................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download