24
Letter from the Chair 2 by Paula M. Hodges Spreadsheets and Specifications 4 by Howard Callif Illustration Software Testing—Part 1: Interface Testing 7 by Joe Alaimo Illustration Software Testing—Part 2: Calculation Testing 11 by Joe Alaimo High-Performance Computing: the Modeling & Trading Platform of the Future is Here Microsoft is Enabling Secure, Affordable HPC Solutions across the Enterprise 16 GPS—Don’t Leave Home Without One!! 19 by Paula M. Hodges Wireless Print Server: The Next Device on your Home Network? 22 by Shyamal Kumar Book Review: Data Quality and Record Linkage Techniques 23 by Kevin Pledge T ECHNOLOGY S ECTION “A KNOWLEDGE COMMUNITY FOR THE SOCIETY OF ACTUARIES” Issue No. 25 • October 2007 CompAct Inside

T S ECTION Issue No. 25 • October 2007€¦ · Letter from the Chair by Paula M. Hodges It is with very mixed feelings that I write this, my last letter as Chair of the Technology

  • Upload
    others

  • View
    1

  • Download
    0

Embed Size (px)

Citation preview

Page 1: T S ECTION Issue No. 25 • October 2007€¦ · Letter from the Chair by Paula M. Hodges It is with very mixed feelings that I write this, my last letter as Chair of the Technology

Letter from the Chair 2by Paula M. Hodges

Spreadsheets and Specifications 4by Howard Callif

Illustration Software Testing—Part 1:Interface Testing 7by Joe Alaimo

Illustration Software Testing—Part 2:Calculation Testing 11by Joe Alaimo

High-Performance Computing: the Modeling& Trading Platform of the Future is HereMicrosoft is Enabling Secure, AffordableHPC Solutions across the Enterprise 16

GPS—Don’t Leave Home Without One!! 19by Paula M. Hodges

Wireless Print Server: The Next Device onyour Home Network? 22by Shyamal Kumar

Book Review: Data Quality and Record

Linkage Techniques 23

by Kevin Pledge

T E C H N O L O G Y S E C T I O N“A KNOWLEDGE COMMUNITY FOR THE SOCIETY OF ACTUARIES” Issue No. 25 • October 2007

CompAct

Inside

Page 2: T S ECTION Issue No. 25 • October 2007€¦ · Letter from the Chair by Paula M. Hodges It is with very mixed feelings that I write this, my last letter as Chair of the Technology

CompAct2 CompAct2

Letter from the Chairby Paula M. Hodges

It is with very mixed feelings that I write this, my last letter as Chair of the Technology Council.It’s hard to believe that it’s been three years since I was elected to my term on the Council.During that time, it has been so exciting to see the work done by the active members of ourSection. I’m disappointed that my time on the Council is coming to an end, but very pleasedwith the new leadership that is coming on board. I leave the Council in the very capable handsof Kevin Pledge, who will be taking over as Chair during the 2007-2008 Council year.

If you’ve been following the section activities, you can feel the excitement that is growing inour area of the SOA. There are so many people who have contributed, I risk missing someone.However, I’d like to publish my thanks to some people by name. First, thanks go to the outgo-ing board members who have served on the Council with me over the last three years: DeanSlyter, who has contributed on the Web site and on the XtbML standard table format; andNariankadu Shyamalkumar (Shyamal), who has helped breathe life back into our newsletter,and ensured its delivery on a quarterly basis over the last two years.

Also, thanks to our current Vice-Chair and incoming Chair, Kevin Pledge, for his endless enthu-siasm and ideas on how our section can do more, and more, and more … Last year, Kevin puttogether a spectacular agenda of sessions for our annual meeting. This year, he’s spearhead-ing the development of a collaboration portal for our section.

Other Council members serving their last year during 2007 and 2008: Van Beach who is active-ly working on coordinating a webinar to highlight the benefits and approaches for record link-age; and Tim Rozar who was our Web coordinator last year and spring meeting coordinator thisyear.

Our Council members who began their terms last year at this time:

David Minches: Annual meeting coordinator for 2007.

Carl Nauman: Survey coordinator and Council representative on the Scenario File project.

Joe Liuzzo: Secretary/Treasurer and currently planning ongoing maintenance for the SOA’sTable Manager.

Other significant contributions were made this year by:

Steve Strommen (lead), Joe Alaimo, Chris Clark, Erin Cole, Steve Craighead, Mark Horowitz,Carl Nauman, Anton Pineda, Michael Pustylnik, Tan Vu Nguyen—Scenario Generator file formatteam members.

Gary Lange—Speculative Fiction Contest.

Carol Marler, Steve Rubenstein, Shiela Silva—Education Committee.

Of course there were many others who contributed articles to our newsletter, were speakers atthe SOA meetings, or helped the section in another way. My thanks go to you as well.

Paula M. Hodges, FSA,

MAAA, is manager of

Modeling Strategy with

Allstate Financial in

Lincoln, Neb. She can

be reached at

[email protected]

Page 3: T S ECTION Issue No. 25 • October 2007€¦ · Letter from the Chair by Paula M. Hodges It is with very mixed feelings that I write this, my last letter as Chair of the Technology

CompAct 3

Thank you, one and all. So much progress has been made, and it couldn’t have been done with-out some great teamwork. I’m looking forward to thanking some of you personally at theAnnual Meeting in Washington, D.C. See you there!!

Paula M. Hodges

Chair—Technology Council

From Incoming Chair of the Technology Council, Kevin Pledge

At the Annual Meeting in October, Paula Hodges will be completing an outstanding year as chair of theTechnology Council.

Over the last year the Technology Section has built on initiatives from previous years and started some newones. On the networking and communication front we have provided networking opportunities at various meet-ings, met our objective to produce four newsletters over the year, updated our section of the SOA Web siteand recently completed a membership survey. We have provided input on enhancing technology education foractuaries, contributed first-class sessions at SOA meetings and, thanks to efforts from Van Beach and ThomasHerzog, we will soon be sponsoring our first webinar. The Scenario Format Project has developed an XML for-mat for sharing scenarios, as well as developing a utility reading, writing and viewing scenarios. We have alsomade progress to secure the long-term management of the Rate Manager—a tool, originally developed bySteve Strommen that so many actuaries rely on. Finally, we have started to investigate portal technology toimprove our internal communication and management.

Thank you Paula for your leadership on all these projects. As Paula hands this responsibility over to me, myimmediate goal is to ensure these projects stay on track. New initiatives will be based on the survey resultsand feedback from you. So please contact me or any council member with your thoughts.

Two other council members are also completing their term on the council—Dean Slyter and ShyamalNariankadu. Over the past three years they have both made significant contributions to the section. Shyamaldeserves special thanks and recognition for his role as newsletter editor; when he took on this role over twoyears ago, we hadn’t published a newsletter for some time—maybe one or two over a couple of years. UnderShyamal’s guidance, CompAct has developed into a high-quality, regularly published newsletter.

As we look forward to the coming year, I need to put a call out for volunteers. Our council and volunteers area special group of people dedicated to furthering the goals of the section, but we are stretched thin from allthe projects we have on the go. Shyamal has completed his term as newsletter editor, so we are especiallykeen to fill this role and to support this with an editorial committee.

You don’t have to be elected to the council to get involved with the section by taking on roles such as newslet-ter editor, meeting coordinator or to volunteer in other ways. So, if you have an interest in any aspects of tech-nology and you want to volunteer, please contact me ([email protected], 905.475.3282 x2#)or any council member. A full list of our council members can be found on our Web site.

Letter from the Chair

Page 4: T S ECTION Issue No. 25 • October 2007€¦ · Letter from the Chair by Paula M. Hodges It is with very mixed feelings that I write this, my last letter as Chair of the Technology

Spreadsheets and Specifications

By Howard Callif (with contributions from COSS staff members Kevin Cottrill,Kenneth Hanson, Thomas Rhode, David Schultz and Stewart Shay)

D o you create or use spreadsheets? Doyou need to provide specifications foryour Information Systems department

or external companies to implement? It is verycommon for documentation to be either ignoredor done last when developing products or im-plementing policy changes. I believe actuarieswould benefit from more training on creatingspecifications, and this is the first of a series ofarticles to help make this task easier. I wouldlike to tailor the articles to your needs, so pleaseprovide comments and feedback on what youthink would be most helpful.

This article will focus on spreadsheets asspecifications, and will provide a wide rangeof tips and suggestions to make your spread-sheets easier to understand, and as self-doc-umenting as possible. Follow-up articles willfocus on what real specifications look like, andwhy they are so helpful.

All spreadsheets are specifications to a certainextent, since they are usually the benchmarkssystems are tested to. Since this is often thefirst place calculations are created, specifica-tions will often be created from the spread-sheet. In a worst-case scenario, the spread-sheet becomes the specifications document,which is handed to an internal systems areaor an outside vendor!

For all these reasons, it is important to makethe spreadsheet as clear and understandableas possible, and include documentation onusage and construction. This article will pro-vide a few guidelines, focusing on the mostimportant suggestions and best practices I’veseen. In fact, following these tips will gener-ally result in smaller spreadsheets, shorterrecalculation times, and will make you (orsomeone else picking up your work) moreproductive.

• Start on the right foot! Name the spread-sheet appropriately, and include a versionnumber in the name! Have a sheet dedicat-ed to Release Notes, and mark changes asyou make them (especially after there areseveral versions of the spreadsheet, or sev-eral people have a copy). If external refer-ences exist, note them, and include themwhen you send the spreadsheet to some-one. If you start from an existing spread-sheet, add this if it is missing. There is noeasy way to show differences between twodifferent spreadsheets, so notes are critical,and can quickly help explain what haschanged.

• Organize the spreadsheet! Keep fields thatare associated together. Place inputs in onecolumn, in a separate sheet, with a bluebackground for each input. This will makeit easy to store a set of clients, to avoid re-entering cases, and enable running a batchwith a macro. Try to keep dependencies onthe left, so the calculations flow, and formu-las reference cells in an organized fashion.

CompAct4

Howard Callif is a

senior system

architect at COSS in

the Illustrations unit.

He can be reached at

[email protected].

Page 5: T S ECTION Issue No. 25 • October 2007€¦ · Letter from the Chair by Paula M. Hodges It is with very mixed feelings that I write this, my last letter as Chair of the Technology

Spreadsheets and Specifications

CompAct 5

There are some other ways to organizeinformation:Use named fields as much as possible. Thismakes formulas much more readable! Youcan easily create a table of named fields,which documents the ranges names and cellreferences (In Excel 2003, you click on themenu item Insert, then Name, then Paste,and then click on Paste List, and a list ofrange names and reference cells will be cre-ated starting in the currently selected cell).

Use selection lists for items that have spe-cific inputs (Yes/No, etc.). Validate data, orat least include notes on what is valid. Evenif it is a text comment, it is much easier tobe told Y/N in the input, than to have to fig-ure out what the input should be. If possi-ble, use the marketing names for fields, ornote them next to the selection.Underwriting classes are notoriously difficultto identify, but there are other instanceswhere not everyone uses the same termi-nology.

Numerical codes simplify lookups, and min-imize “If” statements within the spread-sheet. The preferred approach is to useselection lists as input fields, and then con-vert that to a numerical value in a cell to theright. This is an example of the Do It Oncerule we will discuss below. For example,underwriting classes are usually letters (ora selection list), and converting the class toa number (using a formula, table, etc.), willenable rate lookups to use the class numberdirectly. Coding hundreds of rows of “If”statements looking for preferred takes upspace, is difficult to read, and is harder toupdate.

Code all formula dependencies in thespreadsheet! It is common to have circularreferences that are not apparent, frequent-ly leading to serious implementation prob-lems for administrative or other systems.Many times features such as solves are notimplemented in a spreadsheet, because

they are too complex. However, manydependencies can be coded with a simple“If” statement. For example, Target andMinimum premiums are frequently calculat-ed, but the formula to select them as a pre-mium input is usually not entered, so pre-mium on an illustration is usually not adependent reference. Doing so would iden-tify a problem with a UL policy that has aminimum premium depending on thecharges in the first year (which depends onthe premiums paid).

Don’t be afraid to start a newsheet! Don’t put calculationsthat don’t fit in the bottomright corner, a separate sheetis easier to find and ignore, asthe case may be. There is cer-tainly a tradeoff betweenusing a new sheet, and put-ting a large number of calcu-lations in one place. The audit functionalitycannot be used to track formulas on differ-ent sheets, and it is a shame to lose thisvery useful feature. However, many timesthere is too much information on one sheet,and it becomes almost impossible to findinformation. A sheet labeled COI is veryeasy to find, and the total can be gatheredto another sheet where detail is not shown.

• Two complementary rules: Avoid duplica-tion, and not too much in one line. Usuallybreaking one of these rules leads to break-ing the other. Have you ever seen a spread-sheet with nine rows of text in the formula?It is not easy to debug or evaluate. Manytimes, the same condition is tested repeat-edly, or the same value is calculated in sev-eral conditions of the formula. Have one col-umn test the condition (is the rider on, arewe in corridor, etc.), and then create a sec-ond column to calculate the correct value.For example, instead of trying to calculateall of the riders in one cell, split them apartinto separate columns, and put this detail in

(continued on page 6)

Use named fields as muchas possible. This makes for-mulas much more readable!

Page 6: T S ECTION Issue No. 25 • October 2007€¦ · Letter from the Chair by Paula M. Hodges It is with very mixed feelings that I write this, my last letter as Chair of the Technology

CompAct6

a sheet labeled Rider Detail. Refer to thetotal in the main sheet, and make a notewhere the detail can be found. Rangenames can make this clear, easy to navigateto, and easy to reference.

• Use comment fields, especially for inputfields and numbers. Examples and formulascan be combined with range names, to pro-vide a powerful and clear view of what isbeing calculated, and how.

• Show the precision used in the calculationor include a note if more precision is usedthan is shown. Rounding in Excel is differentthan most programming languages (and itoccurs in intermediate calculations), so ifyou have a say in the formula, avoid round-ing until the last step. Note that when sum-

ming, always sum the smallest to largestnumber.

• A few additional miscellaneous tips: Do nothide any cells, columns or sheets. Set theprint area for each sheet, and try to limit itto letter size, large enough to read withouta microscope. If a spreadsheet is not com-pleted, please include notes on what isn’tworking.

I hope you find these hints and ideas help-ful, and that this article will spur you tointegrate additional documentation intoyour spreadsheets. This is certainly not anall-inclusive list, but if you have some ideasor hints that you think are critical, pleaseforward them to me. :

Two-part series of articles on Illustration

Software Testing by Joe Alaimo, president of

ProComp Consulting, has been chosen by

the Technology Section Council as the

CompAct Article(s) of the Year 06-07. Joe

receives an iPod Shuffle for his much appre-

ciated and informative contribution to

CompAct. Congratulations Joe!

CompAct Article of theYear Prize 07-08

The Technology Section Council will choose

a CompAct article published between June

2007 and May 2008 for the award of the

CompAct Article of the Year Prize 07-08. The

author of the chosen article will either

receive an iPod Nano 4GB or equivalent MP3

player. In the case of multiple authors, each

author will receive the stated prize.

Winner of the CompAct Articleof the Year Prize06-07

Page 7: T S ECTION Issue No. 25 • October 2007€¦ · Letter from the Chair by Paula M. Hodges It is with very mixed feelings that I write this, my last letter as Chair of the Technology

CompAct 7

Illustration Software Testing—Part 1: Interface Testing

by Joe Alaimo

Illustration software testing frequentlytakes far too much effort and time to com-plete. Often, the field force finds bugs in

the first week of the software’s release. Thecause of this is usually due to two major factors:the lack of proper test case development andthe use of manual testing instead of automatedtest methods.

Creating automated testing programs andprocedures are usually perceived as unneces-sary and a waste of time and resources.Writing testing programs is usually only con-sidered at the end of the project when testingis ready to begin and the common argumentagainst them is that it would take too long todevelop and delay the completion of the proj-ect. The truth is that automated proceduresactually reduce the length of the testing cycleand allow for the delivery of a much more sta-ble system.

Once a product is released to the field, thenumber of people testing the system will growfrom a few to a few thousand! If a system isreleased that has not gone through propertesting procedures, any bugs the system mayhave will almost certainly be found by theagents within the first week of its release. Ifthe field finds too many problems with thesystem they may lose all confidence in thesoftware. This can result in the field not usingthe software at all or doubting every resultthat the software produces.

Using automated test procedures is a must ifthe goal is to deliver a stable system andreduce the testing cycle.

This article is the first of two parts. This first partwill outline the benefits of automated softwaretesting procedures for the software interface.The second part of the article that will appear in

the April issue will focus on the calculations aswell as provide a methodology of when andhow to create test cases.

Interface TestingEven when companies use automation to testthe calculations, they often overlook the ben-efits of using automation for interface, busi-ness rule and report testing. This articledescribes some of the interface testing toolsavailable, some criteria on selecting testingstaff and the benefits of using automatedinterface testing.

ToolsThere are a number of tools that are used byquality assurance professionals to performautomated testing. Some of the more com-mon tools are WinRunner, Test Complete andRational Robot.

All of the tools have the same core function-ality and offer the same basic features. Thetools have the ability to record all actionsperformed on a software application includ-ing keystrokes and mouse clicks. Theseactions are recorded and saved as scripts.The scripts can then be automaticallyreplayed to reproduce the same actionsaccurately and consistently.

The tester can create many scripts to repro-duce many different scenarios. This bank ofscripts can be run automatically by the testprogram and in any order desired by thetester. This allows the tester to run the com-plete bank of scripts unattended either duringa daily run or overnight. The test programrecords the results of the scripts and providesa log of any problems that occurred during therun.

Article of the

Year 06-07

(continued on page 8)

Page 8: T S ECTION Issue No. 25 • October 2007€¦ · Letter from the Chair by Paula M. Hodges It is with very mixed feelings that I write this, my last letter as Chair of the Technology

CompAct8

Using a testing tool allows the same key-strokes to be tested in the same order inwhich they were originally entered. The test-ing tool can perform these keystrokes consis-tently and much quicker than a person per-forming the same task.

Selecting Testing StaffWhen selecting testing staff, we have devel-oped guidelines to assist us in our selections.We have found that following these guidelinesallows us to choose people that find the mostnumber of problems and provide the mostunbiased testing.

• Do not choose a programmer: Althoughthe tester will need some basic program-ming expertise to use the testing scripts,they should not be a developer who wasinvolved with the system. It is also best tonot choose a programmer at all.Programmers will usually have an in-depth knowledge of how Windows worksand how a user interface works withinWindows. They will be more likely tounconsciously interact with the interfacethe way it was intended. There is a lotmore value in performing unexpectedactions during testing, as this will moreclosely mirror what a real user will do.

• The tester should not know how the systemworks internally: It is important that thetesters have as little knowledge as possible

of how the system works internally. AtProComp, we ensure that the testers haveno knowledge of our system architecture.The less the tester knows, the more unbi-ased they will be in their testing.

• The tester should not be an insuranceexpert: This seems like an odd require-ment because we usually try to find peo-ple with the most insurance knowledge. Itis important that the tester have insur-ance knowledge, but if they know toomuch then they will unconsciously givethe system all of the correct values. Theymay need to know as much as a typicalinsurance agent, but not as much as yourmarketing personnel.

• The tester should have quality assurancetraining and experience: Some peoplebelieve that this is a step that can beoverlooked. Nothing is further from thetruth. It is important to use testers whoare familiar with quality assurance proce-dures. Entering cases and randomly usingthe system are a small part of the qualityassurance process. Proper quality assur-ance procedures include test case plan-ning and development, entering thecases, running the test cases, test casereporting and regression testing through-out the project. Using a person who isunfamiliar with these procedures will usu-ally result in many important steps beingoverlooked or forgotten.

TimingThe first question that is usually asked aboutautomated interface testing is when it shouldbegin. The first step in testing is the planning.Before testing can begin a test plan must becreated and scripts must be generated fromthis test plan. The plan can begin develop-ment on the first day the project begins. Theplan includes the kind of scenarios that needto be addressed in the testing.

The actual script creation cannot begin untilan initial version of the system is available to

Illustration Software Testing—Part 1: … • continued from page 7

Page 9: T S ECTION Issue No. 25 • October 2007€¦ · Letter from the Chair by Paula M. Hodges It is with very mixed feelings that I write this, my last letter as Chair of the Technology

(continued on page 10)

CompAct 9

work with. When we develop a system atProComp, we start by creating an interfacespecification. From this specification we createthe user interface in our development envi-ronment. This interface has no functionalityattached to it but allows the team to analyzethe “look and feel” of the system. Once thisinterface is given final approval then it can beused to develop the test scripts. This interfacewill not have any logic built into it yet, but thetest scripts can be created and tested whilethe logic is being built into the system. Whenthe system is ready to test, the scripts havealready been generated and testing can beginimmediately.

BenefitsThe benefits of automated interface testingover manual testing are numerous and quitecompelling.

• Problems are easily reproducible: When asystem is tested manually, a person or agroup of people usually will spend a lot oftime entering data, clicking on different partsof the interface and trying many combina-tions of options and features until they pro-duce a problem. Often when they find a prob-lem, they cannot reproduce it because theydon’t remember all of the steps they wentthrough just prior to the error occurring.

Problems that occur in an interface are differ-ent than those that occur in calculations.Reproducing the problem does not onlydepend on the current state of the system,but is dependent on how the system reachedits current state. The exact order of steps per-formed prior to the error occurring is impor-tant because entering the same data in a dif-ferent order may not produce the error.

Automated testing alleviates this problembecause when an error occurs, the exact stepsare recorded. Furthermore, these steps can bereproduced every time. Thus when the problemis fixed, we can be confident that the exactproblem we encountered has been resolved.

• Ability to run regression tests more often:One complete testing cycle consists ofrunning all of the test cases and docu-menting all of the problems found. Theseproblems are then relayed to the develop-ers who fix all of the known bugs. At thistime the cycle begins again with thetesters re-running all of the test cases toensure that the known bugs have actuallybeen fixed and to see if new bugs havebeen introduced. The fixed bugs aremarked complete and the new bugs areadded into the bug tracking system. There-running of test cases is called regres-sion testing. This cycle of test-fix contin-ues until all of the known bugs have beenfixed and no new bugs are found.

When the regression test is performed manu-ally, the process can take a week or more tocomplete. At best the tester will follow a scriptthat is outlined on paper. At worst they are leftto attempt to re-test the problem from the listof documented bugs. This method has thebuilt in risk that the tester will accidentallyskip a step while testing and may assume thatthe bug is fixed when it really isn’t. Also, if thetester does realize that they have missed astep until later in the script, they will have tore-start at the beginning of the script.

When using automated testing, the regressiontest can be run over a number of hours, or runovernight. This reduces the test cycle to run-ning the test overnight and documenting anyproblems the next day. The cycle is reducedfrom one week down to one day! Since thetest-fix cycle usually consists of four or morecycles, the total time reduced from deliveringthe final product can be one month or more.

• Automated tests will find problems thatmanual methods will not: There is no sci-entific basis for this statement, but myexperience has shown automated testinghas found problems that just were notfound using manual methods. This may bedue to the fact that testers usually createmore test cases when using automated

Illustration Software Testing—Part 1: …

Joe Alaimo, B.Sc.,

ASA, is the

president of

ProComp

Consulting.

ProComp specializes

in illustration system

consulting including

system develop-

ment, concept

development,

calculation engine

development and of

course, interface

and calculation

automated testing.

Joe can be reached

at (416) 949-2667

or joealaimo@

rogers.com.

Page 10: T S ECTION Issue No. 25 • October 2007€¦ · Letter from the Chair by Paula M. Hodges It is with very mixed feelings that I write this, my last letter as Chair of the Technology

testing. After all, a few or even 100 extratest cases don’t take any extra time to runwhen testing is performed overnight. Theonly extra effort used is when the casesare first created.

• The same tests can be run on multipleplatforms: Manual testing requires one ormore testers to sit in front of the comput-er running through test scripts or scenar-ios. If the mandate is to test the systemon multiple platforms (i.e., Win ’95, Win’98, Win XP, Win NT, Win 2000) then thesame number of testers must perform thesame tests on each platform. This caneffectively double, triple or quadruple thetesting time in person hours. This wouldrequire you to hire more testers orincrease the testing time as each platformis tested one at a time. When using auto-mated testing, the same scripts can berun at the same time on each platformwith minimal resources. The only extra

time may be due to documenting theproblems found on each platform, if theproblems are platform specific. This offersincredible savings of time and resources.

ConclusionAutomated interface testing requires properplanning and extra initial effort; however, theoverall benefit is a reduced testing cycle thusallowing the product to be shipped sooner. Theproduct will also be more stable because morecases are tested and they are tested on moreoperating system platforms.

This article covered automated interfacetesting of illustration systems. My next arti-cle will discuss automated calculation test-ing. I will illustrate the savings in time todelivery using an automated calculation sys-tem, describe the benefits of automated cal-culation testing and provide some tips ontest case development. :

Online Dues/Section Membership Renewal

Now you can pay your annual dues and sign up for SOA and IAA professional interest

sections with our new easy-to-use online payment system! Just visit

http://dues.soa.org. Using your credit card, you can pay your dues, renew section

memberships or sign up for new section memberships. Online dues payment is just one

more way the Society of Actuaries is improving your membership services. Renew at

http://dues.soa.org today!

CompAct10

Illustration Software Testing—Part 1: … • continued from page 9

Page 11: T S ECTION Issue No. 25 • October 2007€¦ · Letter from the Chair by Paula M. Hodges It is with very mixed feelings that I write this, my last letter as Chair of the Technology

In my first article I focused on auto-mated interface testing of illustrationsystems. In my opinion, the imple-

mentation of automated interface testing isone of the most overlooked aspects of illus-tration system testing.

This article will focus on the issue of automatedcalculation testing. Although everyone tests thecalculations in his or her illustration system,many companies don’t use full testingautomation or give the testing process thefocus that it deserves.

Opponents of automated calculation testinguse the same arguments against it as they doagainst interface testing. The biggest is “creat-ing a test system will increase the testingtime.” Upon further investigation this state-ment proves to be incorrect. This article willdescribe the tools and procedures that need tobe set up to perform proper automated calcu-

lation testing. It will offer a timeline analysisthat will show how automation will improve thetiming of the testing cycle and I will also out-line the benefits of automated calculation test-ing.

ToolsDue to the unique and individual nature of lifeinsurance calculations, an automated calcula-tion testing tool will have to be created specif-ically for each project. The tool can be writtenin any computer language with the most com-mon being Visual Basic, Microsoft .NET, C++or inside an EXCEL spreadsheet (using VBA).This system is usually called the test systemor shadow system.

The tool must basically perform the following functions for each case in a test deckof cases:

• Read-in policy information input from afile, database or spreadsheet.

• Perform the calculations thus mirroringthe actual calculation engine.

• Write the resulting output to a file,database or spreadsheet.

• Compare the output from the test systemwith that of the calculation engine usingtolerance parameters (discussed more inthe benefits section).

• Document the results of the comparison,usually outlining which columns did notmatch and in which years they did notmatch.

When differences between the illustration sys-tem and the shadow system are found, thequestion of which system is producing theincorrect answer can arise. It is possible thatthe test system has the error while the calcu-

Article of the

Year 06-07 Illustration Software Testing–Part 2:Calculation Testing

by Joe Alaimo

(continued on page 12)

CompAct 11

Page 12: T S ECTION Issue No. 25 • October 2007€¦ · Letter from the Chair by Paula M. Hodges It is with very mixed feelings that I write this, my last letter as Chair of the Technology

lation engine is correct. The solution to thisproblem is that a calculation specificationdocument must be created at the start of theproject. The calculation specification is usedby the creators of both systems as their cal-culation blueprint. When a difference occurs,

both systems must bechecked against the specifi-cations to find out where theerror has occurred.

It is vitally important that anindependent party create thetest system. This party canbe a second set of in-housedevelopers, the actuarialdepartment (as long as theywere not directly involved in

creating the calculation engine) or an outsideconsulting firm. There is no value in havingthe same people who were involved in devel-oping the calculation engine involved in build-ing the test system. They would just repro-duce any mistakes or misinterpretation of thespecifications in the test system.

TimingAs with interface testing, calculation testingdoes not begin at the end of the developmentcycle, but rather begins from the start of theproject. There are two elements to calculationtesting that begin right from the first day.

The first element of calculation testing is thedevelopment of test cases. This step is total-ly independent of the creation of the testingsystem. The test cases must be planned outand documented (a methodology that can beused to determine the test cases is outlinedbelow). Once the cases have been plannedout, they must be entered into a file, data-base or spreadsheet so that the testing pro-gram and the calculation engine can accessthem. The format of the test cases must bedecided at the beginning of the project sothat both the calculation engine and thetesting system can be developed to read-inthe test cases.

The second element of calculation testinginvolves the development of the test sys-

tem. This system should not take as long asthe calculation engine because it can be alot more customized than the calculationengine. Since this system will only be usedby the testers, a lot of error and businessrule checking code does not need to bewritten into it. The development of this sys-tem should begin at the same time thatdevelopment on the calculation enginebegins. At this time the calculation specifi-cation will already have been developed.

Comparing Automated VersusManual TestingTo illustrate how automated calculation testingcan reduce the length of the testing cycle I willuse an example. Let’s assume the worst-casescenario where the testing system was notbuilt in advance. Therefore, at the time whentesting is to begin, the testing system has yetto be built. We will also assume that we haveallocated 12 weeks to perform our testing. Twoseparate teams have been hired to performthe testing. Team A will perform manual test-ing and Team B will create a test system andperform automated testing.

Team A requires two weeks to run every testcase and manually check the columns to ensurethat they match. During this time they docu-ment any mismatches that they find. Team Brequires four weeks to build their test system.Once the test system is complete they onlyrequire one day to run the testing. Once thetesting cycle is complete, we will assume thatthe development team needs one week to fix allreported problems. Let’s keep track of the test-ing progress over the 12 weeks.

By the end of the second week, Team A has run through all of the test cases once andsubmitted their results to the developers while

Team B is still building their test system.By the end of the third week Team A receivesa new system from the developers and beginstesting.

By the end of the fourth week Team A is halfway through their second testing cycle whileTeam B has just finished their test system.

CompAct12

“As with interface testing,calculation testing does not

begin at the end of thedevelopment cycle, but

rather begins from the startof the project. ”

Illustration Software Testing—Part 2: … • continued from page 11

Page 13: T S ECTION Issue No. 25 • October 2007€¦ · Letter from the Chair by Paula M. Hodges It is with very mixed feelings that I write this, my last letter as Chair of the Technology

(continued on page 14)

Illustration Software Testing—Part 2: …

CompAct 13

The next day Team B has run their first testcycle and submits their problems to thedevelopers.

By the end of the fifth week, Team A hascompleted their second testing cycle andsubmits their problems to the developers.Team B is still awaiting the developer fixesfrom the first cycle.

By the end of the eighth week, Team A hasjust submitted the results of its third testingcycle. Team B, on the other hand, is halfwaythrough getting the problems from theirfourth testing cycle fixed.

By the end of the 10TH week, Team A is mud-dling through their fourth testing cycle, whileTeam B has just completed their sixth testingcycle.

By the end of our 12-week period, Team Acompleted four testing cycles, while Team Bcompleted seven.

The illustration below graphically representsthe above scenario. Team A is shown abovethe line and Team B below. Each tick repre-sents one week.

BenefitsAutomated calculation testing offers a num-ber of benefits over manual testing. The twolargest benefits are:

1) Ability to run regression tests moreoften: The usual test cycle consists ofrunning a complete test, fixing all of theproblems then re-running the completetest. When using automation, the com-plete test can be run so quickly that thedevelopers can request a regression testof all or some of the cases more often.They may make a particular fix and beunsure of the effects on the rest of the

system. In these circumstances, theycan run the regression test immediatelyto find out if the fix had any ill effectswithout waiting until all of the otherbugs are complete.

2) Cases can be run with tolerance specifi-cations: Due to rounding errors that canoccur, the calculations between the testsystem and the calculation engine maynot match exactly. The testing tool,therefore, should be built to comparethe numbers within a certain tolerance.The tolerance can be a single number orcan increase as the policy matures(after all, if the policy is different by$0.50 in year one, then the differencewill grow larger every year). The toler-ance may also increase as a function offace value. These tolerance valuesshould also be programmed so that theycan be set on a column-by-columnbasis.

Comparing the calculations to this degree of precision is nearly impossible when per-formed manually, but a computer program isideally suited to this type of precision.

Test Case DevelopmentDevelopment of test cases is an essentialpart of calculation testing. All test casesshould be numbered and fully documented.This gives the testing team and the develop-ment team a common reference point whencommunicating bugs. It also makes the bugsreproducible.

Calculation test cases can be developed rightat the start of the project. There is no needto wait until the calculation engine is com-plete. The testing team and developmentteam should agree upon the documentationformat of the tests in advance. If testing

Page 14: T S ECTION Issue No. 25 • October 2007€¦ · Letter from the Chair by Paula M. Hodges It is with very mixed feelings that I write this, my last letter as Chair of the Technology

automation is used, then the documentationmay also serve as the automation input file.When developing a series of test cases thefollowing guidelines should be followed tohelp ensure that a broad range of featuresare included in the test deck and to ensurethat when a problem is found, its source canbe easily deduced.

1) Document the test cases: The test casesshould be planned and laid out in advanceof when the actual testing will occur. Thecases should be numbered to provide thetesting team and the development team acommon reference point. The cases canbe entered into a spreadsheet or, if test-ing automation is used, can be enteredinto the format needed for the automa-tion input file. Thus the documentationmay serve two purposes and duplicationof effort can be avoided.

2) Start with a basic case and build upon it:I have encountered the situation a num-ber of times where the first case testedfailed. This first case consisted of aninsured that had mortality and flat extraratings, had multiple riders and multiple

benefits on the policy, paid above themaximum premium and multiple fundswere selected. Finding the problem inthis case is like finding a needle in ahaystack.

It is important to start with a basic case.The typical basic case is a male non-smoker, aged 40 with $100,000 of insur-ance paying a modest premium. No rid-ers, benefits or ratings should be placedon this case. Use this basic case as astarting point for the next series of casesadding one feature at a time. The secondcase might add a rider, the third may adda benefit. When a problem occurs this willhelp pinpoint the problem. If case twoworked successfully but case three fails,then we can be confident that the problemwas with the benefit that was not presentin case two, but was in case three.

Using this method will leave the test deckbroken up into groups of cases, each casein the group building upon the last.

3) Use age ranges as criteria to differentiatecases: When creating test cases, a com-mon mistake is to assume that each indi-vidual age creates a unique case. Threecases where the only difference is that theinsured is age 20, 22 and 25 do not con-stitute three distinct cases. I would saythat this is really just one case. It is a bet-ter practice to break the allowable agerange into three categories: young, middleaged and older insureds. For example, youmay use 18 to 35 for the younger, 36 to 59as your middle aged and 60 to 80 as yourolder range. Your testing team can decidethe actual breakup that will be used. Thismethod should provide you with a bettermix of cases and ensures that time is notwasted testing cases that are too similar.

4) Add to your test deck as unique casesarise: Following the above techniques will

CompAct14

Illustration Software Testing—Part 2: … • continued from page 11

Page 15: T S ECTION Issue No. 25 • October 2007€¦ · Letter from the Chair by Paula M. Hodges It is with very mixed feelings that I write this, my last letter as Chair of the Technology

CompAct 15

provide you with a robust set of casesthat will represent most of the situationsthat will arise. There are, however,unique circumstances that may bethought of when the cases are beingdeveloped or may be encountered duringthe testing. It is important that thesespecial cases be added into your testdeck whenever they are discovered.Examples of some special cases aredeveloping a case where the exempt testmay fail at a specific age or testing a veryspecific combination of multiple insureds,riders and benefits that caused problemsin your previous system. Whatever thesituation may be, it is important to add itto your test deck, so that it can be partof your testing cycle.

ConclusionAlthough it is often perceived that building a calculation test system will slow a projectdown, the truth is that the timelines can actu-ally decrease when automation is used.

Automation allows the test-ing to be performed morefrequently and can quicklyallow the developers todetermine if a new fix hascaused any other problems.This level of testing givesthe developers more confi-dence that their calcula-tions are correct andreduces the number oferrors that are found oncethe system is released. :

“Although it is often perceived that building a calculation test systemwill slow a project down, thetruth is that the timelinescan actually decrease whenautomation is used. ”

Illustration Software Testing—Part 2: …

Page 16: T S ECTION Issue No. 25 • October 2007€¦ · Letter from the Chair by Paula M. Hodges It is with very mixed feelings that I write this, my last letter as Chair of the Technology

High-Performance Computing: The Modeling & Trading Platform of the Future is Here

Microsoft is Enabling Secure, Affordable HPC Solutions across the Enterprise

Reprinted from Windows in Financial Services • www.windowsfs.com

According to Neil Cowit, New York-based HPC solution specialist forMicrosoft Corporation, Microsoft

Windows Compute Cluster Server 2003 pro-vides a secure, cost-effective solution for thecompute-intensive requirements of financialservices.

In a recent interview with Wall Street &Technology, Microsoft CEO Steve Ballmer said,“The way in which performance gains areachieved on computer chips has changed, cre-ating a new challenge for HPC software. Foryears, Intel just kept doubling, doubling, dou-bling clock speeds. Now they don’t doubleclock speeds anymore—they give us twice asmany cores or processors. Figuring out how totake any application and parallelize it so it canrun across multiple cores will be a key, notjust in high-performance computing and notjust in financial scenarios, but in all applica-tions figuring out how to exploit the increasein power that physics is giving us.”

We checked in with Cowit for an update.

WFS: How has Microsoft’s HPC offering beenaccepted since its launch last August?NC: Quite nicely, thank you. Then again, run-ning compute-intensive work in a Microsoft-based environment isn’t new in financial serv-ices. A large Microsoft user base has existedfor several years with some of the largestbanks using Microsoft for their dedicated HPC-computing requirements.

What is new is Microsoft’s focus in this area interms of personnel, product and partners.

Third-party firms DataSynapse, Digipede andPlatform Computing, all Microsoft partners,have large groups of customers. More recent-ly, HP, Dell and IBM announced specializedsales teams and configurations that best fittheir products, plus a number of third-partysoftware firms have begun porting their prod-ucts to Windows Compute Cluster Server.

WFS: What is Microsoft’s value to customersbuilding their HPC environment withMicrosoft?NC: Running an HPC environment on Windowsisn’t simply about technology. It’s about theROI through what I call the economies offamiliarity.

WFS: Meaning?NC: Customers can leverage the skill sets oftheir established Microsoft operations anddevelopment teams to build, run and managethe applications of an HPC environment.Employees are able to access, manage andreport on HPC results via a familiar, Windows-based environment, making them more pro-ductive by performing jobs and reporting theresults via Microsoft Office programs.

We’ve also simplified deployment and man-agement of an HPC infrastructure so you cancome to one place and get an integrated envi-ronment of tools for HPC. It’s all about highperformance and high productivity. For exam-ple, customers familiar with using MicrosoftOperations Manager and related managementpacks to monitor the health of their IT sys-tems can use the same tools for WindowsCCS.

CompAct16

Neil A. Cowit HPC

solutions specialist,

Microsoft.

Page 17: T S ECTION Issue No. 25 • October 2007€¦ · Letter from the Chair by Paula M. Hodges It is with very mixed feelings that I write this, my last letter as Chair of the Technology

We’ve added familiar management tools,such as a parallel shell, to the ComputeCluster Pack to make management ofMicrosoft-based HPC environments even eas-ier. Plus, developers can leverage the familiarenvironment of Microsoft Visual Studio 2005,building and deploying parallel, Microsoft.NET-based apps to meet changing businessneeds.

WFS: Does all of this apply only to capitalmarkets?NC: No, insurance and banking embrace HPCto refine their models to reduce risk, shortentime-to-market when creating new productsand improve overall operations performance.

WFS: What types of workloads do you seepeople running on Windows-based HPC envi-ronments?NC: We see attention focused on real-timederivatives pricing, risk management model-ing and the like. For example, a Europeancustomer’s structured derivatives businessbuilt its second-generation HPC cluster usingWindows CCS to speed pricing and risk man-agement applications and simplify develop-ment and management—improvements thatallow customers to increase the scale of theirbusiness and shift the focus of IT resourceson solutions for that business.

WFS: Any other examples?NC: We also partner with software and hard-ware vendors to get latency down as far as itcan go. Let’s not forget all the behind-the-scenes batch work completed before the nextbusiness day, as well as those firms usingHPC to migrate work off mainframes.

WFS: What are some of the HPC challengescustomers face today?NC: Well, parallel programming continues tobe somewhat of a black art in financial servic-es. The amount of heavy-lifting necessary tointegrate an existing application to HPC can beconsiderable, but the rewards are high.

Microsoft added tools such as a paralleldebugger into Visual Studio 2005 to speed thedevelopment process, proof that the industrymust continue to develop software develop-ment tools to ease the task of parallel pro-gramming and Microsoft is making significantstrides in this area. Firms like Digipede alsohave some rather exciting .NET developmentand deployment tools that speed integration.

WFS: Doesn’t Microsoft Compute Cluster Packcompete with existing vendors, includingDataSynapse, Platform Computing andDigipede?NC: No, they’re cream-of-the-crop in sched-ulers, Microsoft supports them and they runvery well on Windows Server 2003 ComputeCluster Edition today. Interoperability issomething that has been part of the designgoal from the beginning. Looking back toSupercomputing 2005, Bill Gates spoke anddemonstrated the sharing of work betweendifferent scheduler vendors and differentoperating systems in different parts of thecountry. At Supercomputing 2006, wedemonstrated job scheduler interoperabilitywith Platform Computing using a new indus-try specification.

And yes, interoperability also means sharingwork between Linux and Microsoft HPC envi-ronments.

High Performance Computing …

(continued on page 18)

CompAct 17

Page 18: T S ECTION Issue No. 25 • October 2007€¦ · Letter from the Chair by Paula M. Hodges It is with very mixed feelings that I write this, my last letter as Chair of the Technology

WFS: Is there a business model for systemsintegrators to be successful with HPC?NC: HPC benefits every business in theMicrosoft value chain. Our model’s alwaysbeen built around the system integrator andapplication developer who bring a specializedcapability to the table. Whether it’s depart-mental- or application-based deployment ora firm-wide utility-based deployment, appli-cations do not magically integrate into HPCenvironments. Skilled developers are neces-sary, which is why we’re working with inte-grators Infusion Development, VastComputing, Avanade and Polaris and othercertified partners.

WFS: What’s most difficult in deployingMicrosoft grids?NC: The difficulties are not in deployingWindows. It’s in how you deploy and managean HPC infrastructure within your company.You must understand the political nuances,some of which revolve around deploying autility versus a silo approach, and in defininga charge-back mechanism that doesn’t runcounter to your goal of cost-effective com-puting.

Customers also need to strike a balancebetween tight controls to achieve desiredSLAs and providing flexibility for innova-tion.

WFS: Where do Excel 2007, Excel Servicesand HPC come into play?NC: Excel’s the most wellknown, most utilizedapplication in financialservices. Thanks to theadvancements in Excel2007, multi-threadingenables you to put Excelon steroids. The limits on a

spreadsheets’ size has been greatly expand-ed while multi-threading allows you to setthe number of threads you need to performcalculations in parallel.Excel 2007 also identifies the parallelizablecode areas the first time it runs through thesheet. The second time the sheet is run,

those areas that can run in parallel will thenrun in parallel.

WFS: Take that a step further.NC: User-defined functions can be created.Then these computations can be distributedoutside of the desktop to Windows CCS.

Excel Services opens up a whole other worldof opportunity. Being able to protect your IP,deliver a single version of the truth through asolution built on Excel using HTML and deliv-er performance by distributing computation-ally intensive work through user-definedfunctions to Windows CCS is a solution satis-fying a lot of customers. If you work withparallel computing, incredible performance iswithin reach, and in many cases that speedcan translate into profitability.

WFS: That’s a lot to absorb.NC: There’s a lot to share …

Illustration caption: High Performance and High

Productivity – Windows CCS is designed for HPC

environments. The existing corporate infrastruc-

ture and Active Directory are used for security,

account management and operations manage-

ment. Windows CCS frees developers and admin-

istrators to provide value through their domain

expertise versus spending time building and main-

taining HPC clusters. :

CompAct18

High Performance Computing … • continued from page 17

Excel Servicesopens up a whole

other world of opportunity.

Page 19: T S ECTION Issue No. 25 • October 2007€¦ · Letter from the Chair by Paula M. Hodges It is with very mixed feelings that I write this, my last letter as Chair of the Technology

(continued on page 20)

The GPS is one of those revolutionarytools that are changing the way theworld operates. If you haven’t yet

personally explored the power of one of thesecool gadgets, read on, and find out moreabout what these little gems can do for you.

The GPS is no longer being used by just the“early adopters,” but is truly becoming amainstream purchase as the prices haveplummeted over the last two to three years. Iexpect GPS units to be a very popular itemduring the holiday shopping season this year.Just in case you’re a bit behind the curve, adefinition might be in order. GPS is anacronym for Global Positioning System—whichallows ordinary people to use satellites toknow exactly where they are, right now.Depending on the sophistication and purposeof the particular GPS device, your position isintegrated with mapping software, allowingyou to not only know where you are, but howto get to where you want to be.

I was first introduced to the world of GPSfrom my husband, who is an amateur pilot.He used GPS navigation systems while flying.So, we’ve had GPS units come and gothrough our household for about six yearsnow. We are down to two primary units now—our TomTom unit that we use in the car, andmy GPS running watch.

The TomTom is an example of the most pop-ular type of GPS unit on the market: a self-contained unit that helps you to navigate inyour car. Garmin and TomTom are the leadingbrand names to watch. The TomTom won outin our household, with its easy-to-use touch-screen. If you do any significant driving inunfamiliar areas, or in a large city, this is atool that can save you time and frustration,

and it provides a strong sense of comfort thatyou know where you’re going.

Situations where a GPS unit has helped us out: - Taking a detour because of construction—

the GPS maps a new route to the chosendestination in a matter of seconds.

- When traveling for leisure, an unplannedstop can be calculated into the existing itin-erary. The GPS calculates the extra mileage,and how to get back to the originally calcu-lated destination.

- The GPS can scan the route ahead for gasstations, restaurants and other points ofinterest (POIs) on the planned route ahead.

Cool Features I like- Tells you how far until your next turn, and

what direction it will be.- Displays how many miles to your destination.- Gives estimated arrival time. This uses

parameters such as: the types of roads,whether it is interstate driving, city driving,mountainous terrain. It does a very good jobof answering the question “Are we there yet?”or at least “When are we going to get there?”

- Our unit has its database of roads and POIsstored on an SD card, which we can plug intoour computer and update from the Internetto include new roads, and new POIs.

- Options to change the voice—everythingfrom a “New York cab driver” to “Lori” whosounds like the girl next door. Additionalvoices are available for purchase from thevendor’s Web site.

What To look For WhenGetting Your GPS - Play around with a sample model. See if

you’re able to just pick it up and use it. Youwant it to be easy to use in those situationswhere you’re driving and navigating at the

CompAct 19

GPS—Don’t Leave Home Without One!!

By Paula M. Hodges

Paula M. Hodges, FSA,

MAAA, is manager of

Modeling Strategy with

Allstate Financial in

Lincoln, Neb. She can

be reached at

[email protected]

Page 20: T S ECTION Issue No. 25 • October 2007€¦ · Letter from the Chair by Paula M. Hodges It is with very mixed feelings that I write this, my last letter as Chair of the Technology

same time. If you get a GPS that is toocomplicated, it’s not just frustrating, it’sdangerous.- Look for the accessories that are includ-

ed in the base price of the various units,or how much additional cost for theitems you want. In my opinion, the“must haves” are:

• A carrying case, to transport it inyour suitcase without scratchingthe touchscreen.

• A bracket to mount it to your dash-board—you don’t want to jugglewith it when driving.

• A cable to plug into your car’s ACpower so that you can use it onlong trips without losing thecharge.

Features I’d Change- The menu system is intuitive, but there

is no “easy out.” After navigating to fivelevels deep in the menus, it’s necessaryto hit the “back” button five times to getback to the main screen.

- Add a display for altitude. When taking aroad trip through the mountains, it’snice to know where we’re at on a verti-cal, as well as a horizontal basis.

Watch ItThe other type of GPS that I’d recommendfor hikers, bikers, runners, or other types ofathletes is the GPS wrist watch. I receivedone as a gift last December and really enjoyit. I’ve run a few marathons before gettingthis gadget. As an actuary, I’m interested inwatching statistically how my running per-formance is deteriorating now that I’m in mymid 40s, and this is just the tool to help mein that review.

The unit I own is the Garmin 205 trainer.While running, I’m able to monitor manymetrics: my current speed, distance coveredso far, elevation, and time elapsed. It alsohas all the features a good running watchhas—lap counters, stop/start buttons, and alighted display.

Cool Features:- There are many options to customize

when you want the watch to notify youwhen you’re working out (these are alloptional, and can be turned off):

• you’re going too slow.• you’re going faster than a specified

speed.• you’ve covered a specified distance

(mine is set to beep every mile).- The watch can be set to automatically

“pause” when you’re moving slower thana specified speed, then resume whenyou start moving again. This is nicewhen you stop at traffic lights—it stopsthe timer if you’re moving very slowly ornot moving at all. This enables me tojust turn it on at the beginning of myrun, and shut it off at the end. It does allthe “pausing” automatically for me.

- After a workout, the information can beuploaded to your computer, and the abil-ity to review performance graphically ornumerically is built right into the pro-gram.

GPS—Don’t Leave Home Without One!! • continued from page 19

CompAct20

Page 21: T S ECTION Issue No. 25 • October 2007€¦ · Letter from the Chair by Paula M. Hodges It is with very mixed feelings that I write this, my last letter as Chair of the Technology

- Data and options for different sports can bekept separately on the unit. The built-insports available are running, biking andother.

Features I’d Change- I haven’t found a way to export the data

from the application (to Excel for exam-ple) so I can do analysis on my perform-ance.

- The software needs to be updated for theVista operating system.

- On overcast days, it takes quite a whileto find the satellites, up to 20 minutes.When I want to hit the road, this delay isfrustrating, and I have needed to startmy run without taking the time to waitfor it.

- The size needs to be reduced. I expectthis will happen as the technologyadvances.

- It’s not always easy to figure out how to

change some of the options. It’s one ofthose tools where you need to read theuser’s manual to find out what it can do.

The discovery of GPS technology hasn’tchanged my life, but these gadgets haveadded a layer of security when I’m travelingout of town. I have the comfort of knowingthat I will be able to find my destination. MyGPS watch has allowed me to combine mylove for running with my innate desire to ana-lyze everything. What could be a better gift?

If you’re looking for a new gadget during yourholiday shopping season, a GPS might be justthe thing to buy (or ask for!) :

GPS—Don’t Leave Home Without One!!

CompAct 21

Page 22: T S ECTION Issue No. 25 • October 2007€¦ · Letter from the Chair by Paula M. Hodges It is with very mixed feelings that I write this, my last letter as Chair of the Technology

Wireless Print Server: The Next Device on your Home Network?

by Shyamal Kumar

Searching for wireless networks in asmall neighborhood in Iowa with lessthan 20 homes nets me about half a

dozen (with two unsecured!). This empiricalfact along with the popularity of portable com-puters makes me conjecture that a significantpercentage of actuaries would have a wirelessnetworked home. Assuming that you have awireless network at your home, should youconsider adding a wireless print server to yourhome network?

In our home we have a workstation (two yearsold) and two portable computers (one is sixyears old and the other is a month old), therecent addition running Vista and the othersrunning Windows XP. And with the addition ofthe new portable, the need to be able to printfrom any computer was much felt. A quick fixwas to make the workstation network share theprinter, and hence make the workstation also aprint server.1 This approach would require theworkstation to be switched on while printing,and switching it on every time you wish to printis a chore one surely wants to avoid. A solutionis to leave the workstation working 24/7, whichwhile not very energy efficient was not alsofeasible as I am too much of a paranoiac toleave my Windows box connected to theInternet. Besides, the best way to avoid secu-rity breach is to keep the machine off! This ledme to search for a stand alone print server.

A stand alone print server could be either wiredor wireless. Choosing wireless allowed theaccess point to be in a different location from theprinter, and the one we bought is the DLinkDPR1260 (RangeBooster G Multifunction PrintServer). In the following I describe some of thenice features it has which led me to choose this

over other competing products. First, it has fourUSB 2.0 ports. USB 2.0 transfer speed of up to60 MB/s is about 40 times faster than USB 1.1,and hence much preferable even though mostcurrent devices do not use above 20 MB/s. Thespeed becomes more important if your printer,like ours, does not support postscript. One of thedownsides is that it does not have a parallel port,but as our printer supports USB, and USB 2.0will replace the legacy parallel port, it was a non-issue for us.2 Second, it can also serve as anEthernet bridge providing wireless connectivityto any Ethernet enabled device. In our case, theold laptop benefits from this feature as its wire-less adapter supports only 802.11 a/b and not802.11g standard. Of course, we sacrifice porta-bility for the higher speed. Third, it supportsmany wireless security features which includeWPA-PSK (WPA Home), WPA-EAP (WPAEnterprise) and up to 128-bit WEP encryption.We use WPA-PSK with TKIP encryption on ournetwork (Linksys WRT54G) and required theprint server to support the same standard.Fourth, it is a multifunction print server in thesense that it supports the scan functionality ofmultifunction printers. A short coming is that itdoes not support fax, which to us was a non-issue, but I can easily imagine this being anissue for some others. Also, the multifunctionfeature works currently only with HP products,and the scanning feature does not use the nativescanning utilities.

The setup was easy. The only issue was itrequired a little extra work to get it to tangowith our HP 1022 Laserjet. And we have beenusing it for a month now with no problems atall. If sharing a printer is becoming an issue atyour home, perhaps its time for a dedicatedprint server! :

CompAct22

N.D. Shyamalkumar

ASA, an assistant pro-

fessor of

statistics &

actuarial science

at the University of

Iowa, is a member of

the technology sec-

tion council.

He can be

contacted at

shyamal-kumar

@uiowa.edu

1 An article which provides the steps for doing this in XP can be found athttp://www.microsoft.com/windowsxp/using/networking/expert/honeycutt_july2.mspx

2 Parallel port has transfer rates about 2MB/s and is hence about thirty times slower than USB 2.0.

Page 23: T S ECTION Issue No. 25 • October 2007€¦ · Letter from the Chair by Paula M. Hodges It is with very mixed feelings that I write this, my last letter as Chair of the Technology

Multi-million dollar reserves, pricing

assumptions and the very survival

of companies and pension schemes

depend on the quality of the data used for

analysis. However, little in our actuarial train-

ing prepares us for real-world data issues. As

a result, data quality checks are often limited

to testing averages, trends and spotting out-

liers, yet significant issues exist between the

multiple systems that are used within an

organization.

Finally, a resource is available to guide you

through the data quality maze—Data Quality

and Record Linkage Techniques by Thomas

Herzog, et al. As you would guess from the

title, is a comprehensive anthology of meth-

ods for joining records to improve the quality

of the data. This book covers methods and

models used to link records, supported with

examples and case studies. The mix of math-

ematics, practical examples and case studies

make for an interesting cover-to-cover read;

the book is equally effective for readers who

need to dive in to solve a particular problem.

Suppose you have more than one source of

data; for example:

• employee records and claim records for an

employee benefit plan that need to be

joined, or

• an insurance company that has more than

one administration system and the need to

identify clusters of risk,

• you plan to enhance internal data with

external data records, as discussed at the

Technology Section session “Competing on

Analytics” at the last annual meeting.

Data Quality and Record Linkage Techniques

explains various techniques that can be used

to join these records; not only does it explain

the methodology behind the techniques, but

it also discusses when each approach is most

applicable.

The book finishes with a roundup of data

quality software available. The discussion of

software ties back to the techniques

explained earlier in the book—this is critical

as there is too often the tendency to naively

implement software and trust it as appropri-

ate.

Who should read this book? The short answer

is everyone who is concerned about data

quality and what can be done to improve it.

Buy a copy for yourself; buy another copy for

your IT support.

The Technology Section has negotiated a dis-

count on the regular price of this book; please

see the coupon included with this issue of

CompAct. This offer is available for a short

time only, so act quickly. If you are reading

this online, after the offer has expired, you

can still buy this book from Amazon.com or

other book sellers. :

CompAct 23

Book Review: Data Quality and Record Linkage Techniques

Authors: Thomas Herzog, Fritz Scheuren, William Winkler Reviewed by Kevin Pledge, Vice-Chair of the Technology Section

Kevin Pledge, FIA,

FSA, is president

and CEO of Insight

Decision Solutions

in Markham,

Ontario. He can

be contacted at

kpledge@

insightdecision.com.

Page 24: T S ECTION Issue No. 25 • October 2007€¦ · Letter from the Chair by Paula M. Hodges It is with very mixed feelings that I write this, my last letter as Chair of the Technology

Nariankadu D. ShyamalkumarCompAct EditorAssistant ProfessorStatistics and Actuarial Science241 Schaeffer HallThe University of IowaIowa City, IA 52242-1409phone: 319.335.1980fax: 319.335.3017e-mail: [email protected]

Technology Section CouncilPaula M. Hodges, ChairpersonKevin J. Pledge, Vice-ChairpersonJoseph Liuzzo, Secretary/Treasurer

Council MembersVan Beach, Council MemberDavid Minches, Council Member2007 Annual Meeting CoordinatorCarl J. Nauman, Council MemberTimothy L. Rozar, Council Member2007 Spring Meeting Program Committee CoordinatorN.D. Shyamalkumar, Council MemberNewsletter EditorDean K. Slyter, Council MemberWeb Coordinator

BOG Partner: Mark Freedman

SOA Staff

Staff PartnerMeg [email protected]

Staff Support Susan [email protected]

Staff EditorSam [email protected]

Graphic DesignerJulissa [email protected]

Facts and opinions contained in thesepages are the responsibility of the per-sons who express them and should notbe attributed to the Society of Actuaries,its committees, the Technology Sectionor the employers of the authors. Errorsin fact, if brought to our attention, will bepromptly corrected.

Copyright© 2007 Society of Actuaries. All rights reserved.Printed in the United States of America.

Technology Section NewsletterIssue Number 25October 2007

Published quarterly by theTechnology Section of the Societyof Actuaries

World Wide Web: www.soa.org

475 N. Martingale Road Suite 600Schaumburg, Illinois 60173www.soa.org