Web enabling and Validation for Pharmaceutical companies

From our practice, we have observed that web-enabling makes validation of an application much easier:

• In a web-based system, every user is using the same version of the software
• Only the (web)server has to be validated, not the individual PC's (the user only uses a browser)
• When using applications located on individual PC's (classic client-server system), applications can (erroneously) interact, leading to false results (e.g. the DLL replacement problem).
• On the working place, PC's can be replaced by (much) cheaper, light browser-terminals, which do not have to be validated or where the validation is much easier than for a PC.

Ultimately, web-enabling makes validation easier

• The classic model: starting from the "User Requirements" (UR) a "Functional Design" (FD) is made, describing all the functionality the application must have. This is then used to construct a "Technical Design" describing how the requirements from the UR and FD will be technically realised. These documents are then used to actually build the application. For validation purposes, also a test protocal need to be written. It describes the tests that the software has to undergo successfully in order to get a validated status. Then the tests themselves have to be performed and documented. If all this is done and all documents are available, the software can be validated.
• The RAD model (Rapid Application Development model). This is a very different way of working: Starting from interviews with the commisionars and future users a prototype is build. The users then test the prototype and steer the further development very actively (e.g. by weekly users - developers meetings). A strict timeframe is usually present for each of the modules. RAD means that all documentation is constantly updated. It also requires a serious envolvement from the commisionars and the future users (which is often lacking in the classic model). Constant updating of documentation seems to be a nightmare for developers but isn't if the following modern development methods are used:
• Design by Contract (DBC): the software is constructed modular (and object oriented) with each module (class) having a contract. A contract means that it is strictly described what the module delivers under which conditions and within which limits. The contract itself is described within the software, and can easily and automatically be derived from the software into a separate document. More information about and an excellent introduction to "Design by Contract" can be found here.
• Writing software documentation within the software. Some programming languages like Java enable to add comments in the source code which can then be automatically retrieved to generate the API (Application Programming Interface) which can easily be converted to the software documentation. For example in Java it is good practice to add special comments just before each class declaration and each method declaration. Using "javadoc" the documentation (API) is then automatically retrieved and put into an HTML file.
  This good practice frees the developer from writing separate documentation. Moreover, if additionally a source version controll system is used which generates the javadoc, the documentation is always up-to-date. Click here for an example.

Computer Chemistry Consultancy, June 2001

Computer Chemistry can also help you with setting up "User Requirements". We then perform interviews with the commisionars and the future users, and prepare a "User Requirements Report", which of course has to be approved by the commisionars. Our knowledge of Chemistry, Pharmacy, and of Informatics makes us very competent in this area.

Note: The DLL replacement problem