Computer Validation. Life cycle of software and systems

   

A wide variety of methods exist for developing software, and new methods are continually emerging. The basic methods for the validation of computerised systems are explained based on the generic cycle shown in figure 9.C-1 below.

A project generally begins with a project charter, in which the project is defined. The main purpose of the project charter is to define which functions should be covered by the future system, and to describe future operations. This document is approved by a steering committee consisting of the senior management of the main stakeholders. The project charter is not a validation document.

The following list provides an example of the issues that may be addressed in a project charter:

• Introduction: Description of the business case, summary of project recommendations
• Aims, scope (which operational functions will be covered by the system) and limitation
• Definitions
• Project activities
• Time schedule, milestones
• Roles and responsibilities within the project, in roll out and in operation

In the following, the core life cycle (no. 1-9 in figure 9.C-1) begins with the validation plan, user requirements, technical design, system creation, installation, validation report and finally the productive operation. Using a change request, which is followed by a new project charter, a new cycle can then be initiated.

Error handling is performed using a small loop: Data input errors and other errors that affect operation rather than the system, are handled via 10-11. A reported error in the system leads to a change request via error handling. In the change procedure, the error is analysed and, depending on the risk, expenditure and available alternative solutions, system operation is resumed either with no system changes, or following a change and the corresponding configuration control and testing. System shutdown, which is covered in detail below, (see chapter 9.F.9 Retirement of computerised systems), can also be carried out as a change request.

9.C.1 "V-Model"

One common model is the V-Model (see figure 9.C-2), which was developed in Germany in the 1980s and today is used as a standard model for the development of software (e.g. also included in GAMP^‚).

Terms:

• The user requirement specification is a document in which the user expresses their wishes for the system. Example: The system must have password protection.
• In the acceptance test specification, the system is tested against the user requirement specifications.
  Example: Does the system have password protection?
• In the system specification or function specification, the user requirement specification is technically detailed and enhanced if necessary, in order to realise the user requirement in a program.
  Example: Password protection with
• Modal dialogue environment (i.e. the user first has to enter information here before further windows of the application become visible),
• Password character "*",
• After three invalid attempts, the user is locked,
• The password must be at least six characters long and contain at least one umlaut, a special character or a punctuation mark,
• etc.
• The technical specification is an explanation for the programmer on how to implement the system specification.
  Example: Database field DbfPsw: 16 Chr, Alphanum, Dlgform. Properties: mod=true, ...
  In program development, the technical specification (function specifications or system specifications) is translated into a functioning or a working program.
• The unit test checks whether the program section - also refered to a module or unit - runs successfully.
• The integration test is used to check whether the technical specification has been adhered to. In the integration test, the suitability and the interaction of the program units are also tested. This is tested using technical detection of the connection and integration. The developer can simultaneously be a tester, although for program units with a high risk, additional measures such as an independent tester, test witness, or similar method may be considered.
  Example: Is the name of the database field DbfPsw? etc.
• In the system test, the program is tested against the system specifications.
  Example: Is the password protection modal?
• During the system installation, the program is installed on a computer in the development environment.

The V model is ideally suited to represent the individual sections up to the finished system. The lower the level in the V model, the more technical the issue becomes. The further to the right of the model, the more time has passed. The individual tests - acceptance tests, system tests and integration tests - are executed against the relevant template documents, user requirements and system specifications or technical specifications.

9.C.2 Software development

Software applications are pure data processing applications in which the keyboard, screen, pointing device and printer are the most important peripheral devices. Applications are developed by a software manufacturer. Typical applications include all office programs used with a business, databases for planning, document management systems, administration of bill of material, work scheduling, and many other examples.

If there is no commercially available program existing that has the required functionality, you may decide to let program such an application from a software programming contractor (see chapter 9.E Validation of computerised systems). You can then receive various quotations and decide to whom you will award the contract after having performed a supplier audit (see chapter 9.G.3 Auditing of suppliers and service providers).

The supplier then produces the further deliverables in accordance with the agreed software development methodology. This method determines which deliverables will be available at which point in time and to what extent, and which quality assurance measures should be applied. The software is usually developed specifically for the contract giver and normally involves the adaptation of commercial or public domain software to the specific internal business requirements.

Terms

• To distribute the work over time and among various employees, the programming or even the coding is broken down into code segments or units.
• A firewall is used to separate the company network and the Internet from each other to prevent external access or influences.
• Entity relationship diagrams describe the structure and interrelations of data records in a database in a graphical method (see figure 9.C-3).

  Figure 9.C-3 Simple entity relationship diagrams

The development methodology of the software manufacturer is very technically oriented and should include the following standards:

• Document management: Controls who creates which documents, how these are approved and where they are stored.
• Management of access authorisations and passwords: Who receives which access authorisations and which points must be taken into account when selecting passwords?
• Servicing and maintenance of internal databases: The code segments and deliverables of employees are often stored version-controlled in databases. This improves the exchange of knowledge. To keep the quality of data, it is important that the entries are harmonised and high as far as possible.
• Technical details such as the DNS implementation in the company network, electronic file system and firewall
• Data backup: How will the backup be performed and how are programs that have been delivered to customers saved?
• Creating entity relationship diagrams: If you work with databases, you first need to determine the content (tables of the database), analyse the relationships of the individual content units to each other, standardise (remove redundancies), and create the corresponding tables.
• Standards for programming: For all standards used, guidelines should be set which regulate issues such as the assignment of names of variables, frequency of comments and notification of changes.
• Error handling: How are errors reported and how are customer informed of errors?
• Training: How are employees trained?

9.C.3 Purchasing commercial of the shelf systems

The quickest and most economical solution is certainly to assess and if appropriate, implement a computerised system that already exists on the market.

When comparing systems, it is best to compile a questionnaire and then check the extent to which the individual systems fulfil the requirements. In the example below, three electronic archiving systems are compared. The comparison is made based on questionnnaires in which the percentage of positively answered questions for each group of requirements are compared to each other in tabular form (figure 9.C-4).

9.C.4 Configuration and customisation

It is important to instruct service personnel that no unauthorised changes are to be made. Changes must always be made in accordance with the change control procedure described in chapter 19.C Change control.

In configuration only flags are switched on or off and a system function works differently, e.g. printing of time and date in US or European format. Changes of this type - modification and configuration - must always be approved and communicated, otherwise errors may occur. For the date in particular, it is more advisable to display the month using the common three-letter abbreviation.

In the context of validation of computerised systems, it is pragmatic to differentiate between the following cases:

• Modification, in which a minor program component, known as a patch, is to be implemented. Modifications should be approved via change management and should lead to the creation of a new version, sub-version, or patch level of the application.
• Configuration in which a system setting is switched on or off. A time control for a mixer is configured to that this can be switched on to a precise minute (or second) between 5 minutes and 150 minutes. Configuration should also be subject to change and version control so that at any time, it is possible to trace the configuration at a particular point in history.
• Parameterisation only has an influence on the sequence of operation, but not on the system. For example, if the mixer is set to 15 minutes, the parameter "mixing time" must be set accordingly. Parameter settings should be recorded in the process logs or batch records and are normally not subject to either change control or version control.