Application software changes

A consistent and appropriate change control procedure must he capable of tracking the system operation and application software. The controls on data are extended to the system of hardware and software that manipulates that data. Here the primary tool for control is a clear and appropriate change control procedure. 

Every change in operating system, the application software (Excel), and significant changes in the spreadsheet will be documented, reviewed, and approved. The documentation will contain ... 

Only upon the successful completion of the integration testing and documentation review should product release be authorized. Once an application software program is released, it should be placed under formal configuration/ version control, and any revisions must follow the requirements of a change control procedure. 

Changes and modifications to application software can introduce as many problems/errors as they solve unless they are rigorously controlled. Site changes and modifications to application software are particularly difficult to manage due to the lack of a formal, quality controlled, development environment. 

The following process is applicable for changes to any component of computer technology that performs functions on regulated products, including hardware, peripheral devices, system software and utilities, application software, documentation, and communications hardware and software. These components can be either purchased from an external supplier or developed in house by the company or its designee. 

Emphasis within the life cycle will change depending on whether computer hardware is bespoke or standard and also on the mix of software categories in which the application software falls. Table 5.2 and Table 5.3 outline the preferred validation approach toward different categories of software and hardware based on the risk the various categories of software pose. 

For combined systems, vendor-updated software revisions may be critical, especially if the updated version supplied by the vendor will have an effect on the interface between the vendor s and the user s software (e.g., if the meaning of a macro command has been changed). The user should obtain information from the vendor on how the updated version may affect the interface. The user should also test his or her software after it has been integrated into the vendor s updated standard software. More details are found elsewhere about Standard Operating Procedures (SOPs) for developing and validating simple as well as complex applications software developed in the user s laboratory. ... 

The aim of a backup log is to provide a written record of data backup, the location of duplicate copies of the system (operating system and application software programs), and the data held on the computer. The backup schedule for the disks can vary. In a larger system, the operating system and applications software will be separated from the data that are stored on separate disks. The data change on a fast timescale that reflects the progress of the samples through the laboratory and... 

Software changes are carried out on a separate development system and are subject to the normal validation testing and documentation updates to the IPC application. Changes to hardware are assessed and tested for compatibility with the enviromnent and the system specification is updated to reflect the current installation. 

This includes computer hardware, operating software with product name and revision number, application software with product name and revision number, network devices with product name, software and firmware revision, cables, documentation such as user manuals and configuration settings. Any changes should be documented following documented change control procedures. 

Version A version is a particular revision of a piece of software, normally described by a number, which tells you how new the product is in relation to other versions of the product. MS-DOS, for instance, is currently in its sixth major version. Major revisions are distinguished from minor ones in this manner DOS 5.0 to 6.0 was a major revision, while 6.0 to 6.2 was a minor revision. This way of marking changes is now relatively standard in marking changes in other OS and application software. Additionally, very minor revisions are indicated with an additional decimal point. Upgrading from DOS version 6.21 to 6.22 involved only a few new files, but it was still an upgrade. 

Equipment validated under a specified set of conditions must be revalidated whenever there is a change in those conditions. For example, changes in application software may influence the correct functioning of the computer system. Revalidation refers to those items of the system that are affected by the change. 

Changes in application software must be managed and documented. All documents which are affected by the change should be defined. The documentation of the change then comprises the... 

The decision on the revalidation of the overall system should be examined in each individual case, depending on the complexity of the application software and the risks involved with the change. 

A link from the application software to enhance/change the environment... 

Masters the SOPs for the software life cycle Develops, changes and operates application software Supports users in using the application software Conducts training for the application software... 

The following systems or system components can be distinguished local area network (LAN), wide area network (WAN), network operating system (NOS), operating system (OS), application software, database management software, standard application software, hardware, documentation and Standard Operating Procedures (SOPs). Table 13.1 provides examples of systems and components, and the types of changes that may occur with each system or component. 

Application software LIMS, EDMS, MRP II system, spreadsheet macros Bug fix, patch, new version, changed macro in the application software... 

Change control (e.g., hardware servers and clients system software operating systems, DBMS, application software)... 

Full offline verification for hardware and application software should be completed prior to the installation of the change. 

Where the boundary of the software changes can be clearly delineated and controlled, only the delineated application software needs to be verified before commissioning. 

It is interesting to see how the majority of changes are made to relatively few of the files, especially when the major software changes are discounted. Specifically, 30 or 40 files seem to be changed in each software version. It is therefore likely that these files are in most need of preventative maintenance, as these either represent the core procedural units of the application or are hard to understand and therefore are a frequent source of misunderstandings, and so often requiring bug fixes. An investigation into these issues is currently an area of continued research. 

The results of the application software integration testing shall be documented. If there is a failure, the reason for the failure and corrective action shall be included in the test results documentation. Any change to the software shall be subject to a safety impact analysis. 

If at any stage of the application software safety life cycle, a change is required pertaining to an earlier life-cycle phase, then that earlier safety life-cycle phase and the following phases shall be re-examined and, if changes are required, repeated and re-verified. 

---