Bespoke application software System

Configurable application software usually includes custom configurable packages such as Manufacturing Resource Planning (MRP 11), Documentum , Maximo and so on. Validation of such systems requires an audit of the supplier and validation of any bespoke application software. 

Software (e.g., operating system, database, application software modules, data sets, bespoke/custom/standard software modules, etc.)... 

Operating Systems Application Software Configuration Bespoke Code... 

Configuration/parameterization and new bespoke development of application software should be carried out in accordance with a software Quality Assurance System (see Figure 4.3). The diagram shows the following relationships ... 

Where the OCS has a standard interface to a particular Fieldbus and the number of installations is such that this can be deemed as standard feature, there is little need for software module testing. This is true of any Fieldbus interface to any control system. In a traditional scenario, where data need to be transferred via the OCS to a maintenance application or a laboratory analysis package, the actual transfer of the data needs to be fully tested as a bespoke application. 

Generally, widely distributed Off-The-Shelf (OTS) software is not considered to need Source Code Review if a reputable developer has produced it under an effective system of quality assurance and the product requires no more than an application parameter configuration. In most computer systems, therefore, Source Code Reviews are limited to custom (bespoke) software and configuration within OTS software products. 

All systems need to be sufficiently reliable and secure in delivering the service that is required of them. Various ways in which this can be achieved in practice range from the use of various validation and verification techniques, to the use of software fault/intrusion tolerance techniques and continuous maintenance and patching once the product is released. Fault tolerance techniques range from simple wrappers of the software components [1] to the use of diverse software products in a fault-tolerant system [2]. Implementing fault tolerance with diversity was historically considered prohibitively expensive, due to the need for multiple bespoke software versions. However, the multitude of available off-the-shelf software for various applications has made the use of software diversity an affordable option for fault tolerance against either malicious or accidental faults. 

---