Where an application provides Audit control functionality, how should this be counted?
The auditors of the Payroll area require all changes to employees' contracts to be recorded.If the changes to the original contract are substantial then a new contract is drawn up.If the changes are minor then they are recorded on the existing form by crossing out the previous data and recording the new information.The auditors require the Administrative Staff to date and initialise their changes or, if creating a new contract, they must record the previous contract number, reason for the changes, the date and their signature.Regular audits produce reports that highlight any suspicious changes and list the previous and changed information along with the name of the person and date of the change.
The developers decide to implement the audit requirement by writing the before and after images of all transactions to a single audit file.The audit file records the User ID along with a system time and date stamp.This audit file may be selectively inquired upon to display or report certain types of changes made on selected dates with different business rules for selecting exception data.
The counting of Audit functionality was a counting issue under Release 4.0 of the CPM. Under IFPUG Release 4.1 a resolution has been provided to the audit issue. This is presented in a specific Audit example on Page 6-26 of the CPM HR System Security. The resolution described below conforms to Release 4.1 and is to be used by FP Analysts.
The audit function described above is a user functional requirement.The elementary processes are the add, and change, of the information (e.g. Add Employee Contract, Modify Contract Details). The audit control fields (User ID and Date) are counted as extra DETs on all the maintenance functions. The Before and After Image of the DETs being changed, count as two DETs only, regardless of the number of DETs being changed.
The Audit reports would be counted as External Outputs or External Enquiries.If the reports use different business logic to extract data from different fields and different files then each report would be counted as a separate unique transaction.If the reporting involves the same logical processing against many files only one transaction (typically of High complexity) should be counted.
The Audit File is not counted as a logical file even though it is often implemented as a physical file maintained by user transactions.Instead, the Audit DETs should be counted as a separate RET on those logical files that require audit trails.
Depending on the application, audit control and reporting of the users business, may or may not be a business requirement.There are situations where the time and date stamping of records is only for recovery purposes and not required by the business.This is most clearly seen in systems where every file has audit DETs associated with it and there are no system functions available to report this data.In these instances, the process is not counted as an audit function. Therefore, unlike the previous scenario, the additional file attributes used for this purpose should not be counted.
Contribution to VAF
Where time and date stamping is considered to be for recovery purposes and not an audit function, it should be included as a feature of 'Backup and Recovery' in the assessment of the GSC 'Operational Ease' in the Value Adjustment Factor.