R.D. McDowall
|
In the June installment of "Focus on Quality" (1), we looked at the classification of software from the new GAMP guide version
5 (2). This was the classification of software into four, or if you preferred my version, five different categories. Now I
would like to spend time in this column looking at the life cycles that are applicable to software in categories 3, 4, and
5.
The reason is that the life cycle associated with each category of software is the main way of determining the amount of validation
work you will need to undertake. But the key to this approach is an honest and accurate appraisal of the software category.
If this is mistakenly or deliberately underestimated — that is, if a category 4 application is classified as category 3 software
— then a laboratory has a compliance hole that will cost more in time, effort, and reputation to sort out later than doing
the work correctly in the first place. However, before we begin, let's recap what these three categories of software are in
case you did not read the thrilling June installment or simply forgot what I wrote.
Software Categories 3, 4, and 5: A Quick Reprise
GAMP version 5 (2) has defined these three software categories as follows:
- Category 3: Nonconfigured Products
Off-the-shelf products that cannot be changed to match the business processes but this category also can include configurable
software products but where only the default configuration is used. - Category 4: Configured Products
Configured software products provide standard interfaces and functions that enable configuration of the application to meet
user-specific business processes. However, configuration using a vendor-supplied scripting language should be handled as custom
components (category 5).
- Category 5: Custom Applications
These applications are developed to meet the specific needs of a regulated company. This definition implicitly includes spreadsheet
macros written using visual basic for applications (VBA) and LIMS language customizations. It also will include macros written
for some spectroscopy software as short cuts for performing a series of tasks. Note that this is the highest risk software,
as there is the greatest likelihood of functional omissions, bugs, and errors in the software, and therefore, the life cycle
model used needs to have sufficient controls to ensure that it is properly specified, designed, built, and tested before release.
GAMP 5 notes that these categories are not silos of software but a continuum: There might be elements of a higher or lower
category depending how the software is used and/or configured or customized.
Why Is a System Life Cycle Model Important?
A software application or a computerized system does not suddenly materialize out of thin air. Each one needs to be planned
and implemented. Therefore, the use of a system life cycle is important as it provides a plan to use as a basis for the implementation
or building of a computerized system.
Note the words:
- Plan: A plan is a blue print or road map for carrying out a task. It will outline the stages or phases that need to be gone
through so that the system will be built correctly and function as required.
- Basis: Plans can be changed to fit the system that is being implemented or developed and you should accept that there is no
one-size-fits-all approach. A specific system can have more, the same, or fewer needs than the standard life cycle model will
provide and therefore, adaptation of the plan might be needed to accommodate them.
Therefore, the key requirement of any life cycle model used is that it should be meaningful and applicable to the system that
you are building or implementing. If it is not, then you have problems.
