Can Validating SAS Programs be Fun and Easy?

Validation is normally a laborious and arduous task. This paper will present new methodologies and tools developed in SAS that will make the process painless. The goal is to add little or no effort from the user's perspective, yet gain the benefit of having a secured audit trail of all SAS programs during the development and verification process. Some benefits are described below:

• comparing differences between different versions of programs
• adding notes describing edit changes to each version
• adding a validation checklist of tasks associated during verification and validation
• managing status of development to production by applying version numbers such as version 1.2
• generating reports for documentation and communication during validation

After you realize the ease of use and the amount of quality control that can be gained, the task of validation becomes transparent and fun.

Introduction
Validating SAS programs presents some unique challenges especially when working within a regulated environment such as the pharmaceutical industry. This paper explores the challenges specific to this environment though the examples can be useful in other environments as well. SAS programmers come from many different backgrounds that range from biology to statistics. The majority are not from a computer science background. This is normally due to the fact that they have expertise in the domain of the data in which they are analyzing. This is helpful for ensuring the outcome of the analyses but creates an unstructured environment for developing SAS programs. The work flow is driven by reports and therefore is usually done in an ad hoc manner. The analyst normally gets mockups of the report which describe what they need to produce. They often jump right into SAS programming with little or no data and programming design consideration. SAS has adapted to this work flow well compared to other more structured high level languages. Other languages such as C or Java are stronger typed. This means that the variables and tables have to be defined with proper variable type and length before they can be used. On the other hand, SAS programs can dynamically create variables as you go along lending itself to the ad hoc nature of the development process. This can be beneficial for creating exploratory analysis and conducting experiments with the data. However, it fosters software development that is riddled with maintenance challenges. The tools used to develop SAS programs such as display managers or text editors are further examples of ad hoc nature. Display manager gives some structure, but it is designed for exploration. Software development tools for other languages allow for the programmer to manage the source code as it relates to other programs and data. On the other hand, SAS programs are plain text files that any user can edit with a text editor of their choice. In a similar way, display manager leaves the programs stored on disk as text files and does not create any other structure upon that.

This is an example of how SAS programming is difficult to validate. Programs are inherently buggy by nature since there is great variability and complexity. It is written by humans but is interpreted by machine. Even though the syntax is set up with constructs to handle the parameters to help, humans do not think in complete logic. This leads to misinterpretations and bugs. SAS programming is often data driven which adds another dimension to the complexity since the data can be dynamic in content and structure. The changes in data drive changes in results and therefore changes in programs. The management of changes of each component and all of its interrelationships makes SAS programs an ever changing organism desperately in need of containment. The issue of change control will become a major strategy in taming the beast and is one of the primary themes of this paper.

One of the attempts to create structure around the chaos is the use of SAS macros. Macros are intended to isolate repeated tasks and parameterize them so that they can be repeated. However, the way macros are sometimes used leads to spaghetti code since one macro calls another macro in a nested loop. This sometimes results in more complexity and becomes more challenging rather than simplifying.

Validation Benefits
There are many challenges in creating an effective validation environment for SAS programs but there are also many benefits that can rationalize the effort. There are reasons to make a strong business case for performing validation. The most obvious is the requirements by the FDA spelled out in CFR part 11. In a regulated environment, it is not just a nice idea to perform validation, but it is a legal necessity. Here are some examples of other important benefits.

1. Less Roll outs – Each time a program is rolled out, it is commonly followed by patches. This is to fix bugs that did not get caught during validation.
2. Prevent Data Corruption – Bugs can be traced back to programs that have not been fully validated. Using these programs creates corruption in the data and reports.
3. Facilitates Communication – The requirements and functional specifications along with the test scripts can be developed with close collaboration with the end user. This leads to a clearer understanding between the user and the developer.
4. Software Maintenance – During validation testing, versioning and an audit trail are created. This helps with tracing and attributing features and bugs. This audit trail leads to better tracking of programs between different releases which helps in the management of bugs and wish list items.

complete paper at: http://meta-x.com/publication.html... , SAS Validation software and SAS Outsourcing.