Time to fix it. Take the Payroll Processing program that you designed in RAPTOR in the last module, and add some additional logic to it. The details of what needs to be checked, and what needs to be done about it, are in this week's spiral development plan.
The plan for this module also asks you to do some thinking about appropriate test data to check your program. Be sure to update the documentation in your RAPTOR program to show when you've modified it and what youve done to it.
Let's take the Payroll Processing program that we designed in RAPTOR in the last module, and add some additional logic to it. We need to have it do the following:
Company-Wide Payroll and Tax Data Input Validation. Validate that all of the input tax rates are logical and correct (not negative; not greater than 100%, certainly). Chances are, there are sensible default values for these parameters, values that are not zero. For example, the withholding rate for Social Security and Medicare taxes does not change very often. So maybe by initializing these values to their sensible defaults, you end up changing the behavior of the user with the program: does the bookkeeper want to accept the defaults, or type in some other in-range number?
In this module, since we're not too skilled and cunning with nested loops well do this as a series of nested IF tests:
INITIALIZE taxparameters to sensible default valuesINPUT taxparameter_1 IF taxparemeter_1 IS within range THEN
INPUT taxparamenter_2 IF taxparameter_2 IS within range THEN
...
...
...
ELSE
Output an error message about taxparameter_2, “default will be used instead”
ENDIF taxparameter_2
ELSE
Output an error message about taxparameter_1
ENDIF taxparameter_1
Do the rest of the program...
Per-Employee Data Validation. Test to make sure that the total number of hours worked is not negative, and not greater than some reasonable maximum (if the pay period covers two weeks, it certainly can't exceed 24*14...), and that the hourly pay rate is less than what you think is a reasonable maximum.
Would our "default values" strategy work here? Or should we use a loop?
As part of this, you'll have to modify the prompts to the user, so that theyre told what "good" data is to start with, vs. garbage data; and then develop the logic that checks the data, and either tells the user Wrong, do over! and prompts for and gets input, or moves on to processing.
STRONG HINT: would these "data validation" chores be a great opportunity to use a subprogram? How would you do this in RAPTOR?
This would then lead us to think about appropriate test data. Test data, we recall, usually is from three logical domains:
Be sure to update the documentation in your RAPTOR program, to show when you've modified it and what youve done to it.