SAS Software Development with the V-Model Andrew Ratcliffe RTSL.eu Coders Corner Paper

Overview Best Practice in SAS software development Process… Flow from: requirements to deployment Via: design, build and test Coding specifics A tip for testing your code Andrew Ratcliffe First used SAS in 1983 Provide services through RTSL.eu Blogging on NOTECOLON.INFO »SAS and software development best practice

Best Practice Always driven and guided by business purpose Repeatable set of steps Allows us to plan »Time, cost, skills, effort Allows us to create templates and guidelines Helps newcomers contribute quickly and effectively Easier to transfer tasks between people Plan – Do – Review Make sure everything got done… got done right Barely adequate Barely adequate Good enough… but only just Good enough… but only just

Outline Development Process

Plan and Do Business Requirements System Requirements Design Specification Unit Specification

Traceability Business Requirements System Requirements Design Specification Unit Specification Well-structured text, not proseWell-structured text, not prose Uniquely identify every elementUniquely identify every element Make sure nothing is missedMake sure nothing is missed Make sure nothing is addedMake sure nothing is added Well-structured text, not proseWell-structured text, not prose Uniquely identify every elementUniquely identify every element Make sure nothing is missedMake sure nothing is missed Make sure nothing is addedMake sure nothing is added

Testing Business Requirements System Requirements Design Specification Unit Specification User Acceptance System Integration Unit Peer Review Coding Standards Coding Standards Defined objectivesDefined objectives Well-structured text, not proseWell-structured text, not prose Uniquely identify every elementUniquely identify every element Repeatable stepsRepeatable steps Test Strategy defines approach, coverage, etc.Test Strategy defines approach, coverage, etc. Make sure nothing is missed/addedMake sure nothing is missed/added Defined objectivesDefined objectives Well-structured text, not proseWell-structured text, not prose Uniquely identify every elementUniquely identify every element Repeatable stepsRepeatable steps Test Strategy defines approach, coverage, etc.Test Strategy defines approach, coverage, etc. Make sure nothing is missed/addedMake sure nothing is missed/added Test Strategy

How will you be sure the system does what it should? Types of testing Static / dynamic Inspection of results & data Baseline for comparison / expected results Automated / manual Coverage 100% Spot checks »How many / which & what Artefacts & evidence to be archived Test Strategy

Test Strategy - Detail Units will leave environments as they found them Aside from planned / designed behaviour No memory leakage (memory freed-up at appropriate times) No temporary libraries remain assigned No temporary data sets remain No macro variables remain 141 %tharness(testmacro=BestCodeEver); THARNESS: Starting execution of code to be tested NLOBS= THARNESS: Execution of code to be tested has finished THARNESS: Summarising results THARNESS: Macro variable has been added: scope=GLOBAL name=NLOBS THARNESS: Library assignment has been added: libname=NFIND_ME THARNESS: End of results summary Coding Standards Test Strategy

Deletes its own temporary WORK data sets Facilitated by the fact that the names of all of the macros WORK data sets are prefixed with _THARNESS_ (achieved generically with _&sysmacroname._ ) By using the same prefix, the data sets can be deleted at the end of the macro by specifying _THARNESS_: on PROC DATASETS DELETE statement Conditional upon &tidy (for debugging) %if %upcase(%substr(&tidy,1,1)) eq Y %then %do; proc datasets lib=work nolist; delete _&sysmacroname._: ; quit; options notes; %end; %mend tharness;

Approach: Snapshot then Compare Snapshot of elements of environment taken before and after execution of the macro-under-test, e.g. sashelp.vslib Comparison of before and after images done with DATA steps and PUT statements (more flexible than PROC COMPARE) data _null_; merge work._&sysmacroname._vslibbefore (in=before) work._&sysmacroname._vslibafter (in=after) end=finish; by libname; retain IssueFound 0; if before and not after then do; put "&sysmacroname: Library assignment has been removed: " libname=; IssueFound=1; end; else if not before and after then do; put "&sysmacroname: Library assignment has been added: " libname=; IssueFound=1; end; if finish and not IssueFound then put "&sysmacroname: No library assignment issues found"; run;

Approach: Snapshot then Compare Data work._&sysmacroname._vslibBefore; Set sashelp.vslib; Run; THARNESS: Library assignment has been added: libname=NFIND_ME data _null_; merge work._&sysmacroname._vslibbefore (in=before) work._&sysmacroname._vslibafter (in=after) end=finish; by libname; retain IssueFound 0; if before and not after then do; put "&sysmacroname: Library assignment has been removed: " libname=; IssueFound=1; end; else if not before and after then do; put "&sysmacroname: Library assignment has been added: " libname=; IssueFound=1; end; if finish and not IssueFound then put "&sysmacroname: No library assignment issues found"; run;

Echoes all of its parameters upon initiation Ensures that the values of those parameters taking default values (and hence not specified in the calling program) are known to anybody inspecting the log %macro tharness(testmacro =,tidy = y ); %put &sysmacroname: Parameters received by this macro are:; %put _local_; %put ; 141 %tharness(testmacro=BestCodeEver); THARNESS: Parameters received by this macro are: THARNESS TESTMACRO BestCodeEver THARNESS TIDY y

Summary Plan – Do – Review Barely Adequate What – How - Build Traceability (vertical) Testing Traceability (horizontal) Peer review – unit – integration – system - user

Thank you for listening. Enjoy your evening! Andrew Ratcliffe NOTECOLON.INFO