Some applications contain the ability to archive data. The archiving of data may either be a business user requirement or a technical implementation choice. Should the archiving of data be counted, if so, how should it be counted?
Archiving is defined as the movement of information from one data storage medium, typically the on-line database, to another off-line data storage medium, typically magnetic tape or cartridge.
Applications that archive data may be doing so for technical reasons or to fulfil business requirements.
Scenario 1 - Technical Requirements
Reasons for removing data from an on-line database include:
The user requires the computerised system to store all pay records for the life of the system but they also require response times of less than two seconds and would like all payroll enquiries and reports to only include pay details for the current financial year.
The developer has recommended two strategies to address these requirements:
Scenario 1 Resolution
The archiving function described above does not satisfy the characteristics of a user functional requirement and is therefore not counted.
The archiving function described above is not a business requirement as the archiving function has been introduced as a part of the implementation/technical solution. The processes that take place are not business events from a user perspective.
The requirement to delete records older than ten years has been implemented as part of the archive function. Whilst archive functionality is not counted, the ability to delete records older than ten years is a user requirement and should be counted even though the delete functionality is associated with the archive functions. Each logical file which has its records deleted would count one External Input. The ‘system date’ whilst it does not cross the software boundary, it is counted as per Section 3.1.5, Batch Functions and Release 4.1.
Assume that two logical files exist, Employees and Payroll, both of which are automatically deleted of all records older than ten years. The deleted records are written to Archive-Employees and Archive-Payroll. Given this example, two External Input transactions would be counted, i.e. Delete Employees Details and Delete Payroll Details.
The archiving function described above does not satisfy the characteristics of a user functional requirement and therefore the archived version of the files are not counted. In the above example, Archive-Employees and Archive-Payroll are not counted.
The logical files, i.e. Employees and Payroll, from which data is archived would be counted once only for the application.
Contribution to VAF
When transactions and files do not account for the archive functions, the following GSC’s should be considered:
· a quality feature of the application i.e. ensures performance requirements are met. This is considered when assessing the GSC ‘Performance’ in the Value Adjustment Factor.
· a technical feature of the application, i.e. file storage space is constrained by the hardware limitations. It is considered in the GSC ‘Heavily Used Configuration’ in the Value Adjustment Factor.
Scenario 2 - Business Requirements
There are cases where archiving data is required for business reasons. For example, applications require data to be maintained for a minimum number of years in order to comply with legal or taxation regulations.
Due to the volatility of the business, customer records that remain inactive for a period greater than six months may be considered ‘expired’ customers, in that they are highly unlikely to place future orders.
The user requires customer records that have been inactive for a period greater than six months to be ‘stripped’ of all non-mandatory data and be stored off-line. The remaining data is sufficient for compliance with relevant legislation. In the unlikely event that ‘expired’ customers re-order, a warning message indicating the customer exists and is archived is displayed to the user. The archived record must be available to the business within 30 minutes.
Customer records that have a system datestamp greater than six months old are ‘tagged’ and archived in an overnight batch job.
The customer details held upon the on-line database are extensive; the customer file contains 3 RETs (Customer, Comments & Customer Associates) and 35 DETs.
Customer records ‘tagged’ for archiving are ‘stripped’ of Comments and Customer Associate details and are written to the Arch-Customer file.
The transaction to retrieve archived customer records is available to the user.
Scenario 2 Resolution
The archiving function described above does satisfy the characteristics of a user functional requirement and is therefore counted. In this instance, the functions that perform the archive and access the archived data would be considered business transactions provided these functions have been custom built and are not being performed by a utility function or another separate ‘Archiving’ application.
Given the above example, the following transactions are to be counted:
Where the data contained in the archive file is sufficiently different to the on-line file, then the archive file should be counted as an ILF if it resides within the application boundary.
If the details held for on-line and archived data are identical or have very minor differences, only the on-line file should be counted. In the above example, the files are sufficiently different and both would be counted. The Customer file is counted as an Average complexity ILF, whereas the Arch-Customer file is counted as a Low complexity ILF as it is a subset of the Customer ILF.
Where the data is stored on another offline data storage medium this is not counted as an ILF, to the applications being counted.
Often there is an internal logical file that records the details of information available from the archive. This functionality would be counted as per standard IFPUG guidelines.