|
Home
ISSUE
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?
Functional Overview
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.
Sample Scenarios
Scenario 1 - Technical Requirements
Reasons for removing data from an on-line database include:
- Remove old records thereby increasing the application's response times
- Conserve disk space
- Remove old records 'cluttering' inquiry screens
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.
Technical Design
The developer has recommended two strategies to address these requirements:
- Implement the user requirements using the existing hardware, which has limited disk storage.Archive all pay records to magnetic tape after Payment Summaries have run for that financial year.This would only leave the data for the new financial year on the production files.Implement functions that allow the user to selectively retrieve, or delete, archived records.
- Implement the user requirements using a platform that can store all data and still maintain response times of less than two seconds.In order to avoid old records 'cluttering' screens and reports, enquiry/report functions will contain a filter that defaults to this year's dates, but allows selection of any date range.
Restrictions regarding physical deletes have been placed upon the users. Users are only able to 'logically' delete, i.e. mark the record for deletion; audit requirements prohibit physical deletion of data. The system date will act as a trigger to automatically delete all records older than ten years. It is a business decision to remove data that is no longer relevant, with ten years being the threshold decided upon.
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.
Transactions
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.
Files
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.
Technical Design
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.
Transactions
Given the above example, the following transactions are to be counted:
- functions to archive the data from the Customer to Arch-Customer file. This transaction is counted as an EI if the Arch-Customer file is stored within the application boundary. The transaction is counted as EO if the Arch-Customer file is stored on another off-line data storage medium, typically magnetic tape, cartridge or CD. The transaction is typed an EO because an archive function is a two staged process. A logical file is updated when the record to be archived is actually removed from the file, and the details are then 'output' from the system.
The transaction is not counted at all if the
Customer and
Arch-Customer file have identical attributes and the transaction merely copies the record to be 'archived' from one file to another. This is typically the case when the archive function has been implemented for technical reasons only.
Count one EI/EO per file read, if the archive function for each file can be triggered independently. The attributes for each logical file are different, hence, uniqueness criteria are satisfied. However, if data dependencies exist, and data is archived from multiple files at the same time, count only one EI/EO. For example, if a record archived from one file requires a corresponding record to be archived from another file, only one function should be counted. The number of files read, contribute to the complexity of the function.
- functions to retrieve archived records from
Arch-Customer and reinstate them to the
Customer file. This transaction is counted as an EI regardless of where the
Arch-Customer file is stored.
- ability to view records held on
Arch-Customer file
Files
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.
|
