Biomedical Engineering Reference
In-Depth Information
Key to maintaining the validated state is the use of an effective change
control and confi guration management process. This is often seen as
contrary to the ethos of some parts of the open source community, where
it is possible (and sometimes encouraged) for users to download and
install the latest functional enhancements, patches and bug fi xes - this
speed of enhancement and the ability to leverage the efforts of other
developers is undoubtedly one of the attractions of using open source
software, especially in innovative applications. However, if this is allowed
to happen the validated state of the software is immediately placed at risk
and appropriate controls must be established. It is possible to allow this
fl exibility, but there are additional costs involved.
This requires a controlled set of environments to be established and
these are outlined in Figure 21.6.
■
A development environment for use by users and developers who wish
to try out new functions, or even play a more participatory role in the
open source community. This can be used to try out new functions
available in the open source community or to develop new functionality,
which may in turn be shared with the wider community.
■
A test environment where new functions are tested - and old functions
regression tested - prior to release into the production environment.
This environment should be under formal change control, should be
qualifi ed in accordance with industry good practice and may be
maintained and supported using formal processes and procedures.
■
An operational environment - which is under formal change control
and subject to clearly defi ned release management processes. This
environment also should be under formal change control, should be
qualifi ed in accordance with industry good practice and should be
maintained and supported using formal processes and procedures.
Although it is possible for very frequent updates to be made to the
development environment (including the download of new functions, bug
fi xes and patches) - sometimes weekly or daily - the release of such software
to the test environment should have a clear scope, defi ned in terms of which
updated requirements will be fulfi lled. Release from the development
environment to the test environment should be subject to defi ned version
management and release management processes and will occur with a
much lower frequency (every two weeks, every month or every three
months depending on how much the open source software is changing).
The test environment should be formally qualifi ed and subject to
change control. This is to ensure that the test environment is functionally
Search WWH ::
Custom Search