Version 2.2 Effective date: 07 January 2013 Author: Approved by: Mr A Willis, Senior Programmer Dr Sarah Duggan, CTU Manager Revision Chronology: Effective Date Reason for change Version 2.2 07 January 2013 Update to remove the defunct guideline: G10-WCTU-PT-Standard Trial Objects and to remove the specified timelines for arranging system review meetings Version 2.1 10 February 2011 Update to acknowledge the Senior Project Manager and System Owner roles Version 2.0 21 January 2009 Re-write to incorporate new procedures for software development Version 1.0 March 2006 Page 1 of 6
1. Purpose This Standard Operating Procedure (SOP) describes the Warwick Clinical Trials Unit (WCTU) Programming Team s procedures for clinical trial software development and maintenance. 2. Background The clinical trial software development process has been tailored specifically to meet the needs of clinical trials. The development process incorporates elements from a number of standard methodologies, in particular UP (Unified Process) and RAD (Rapid Application Development) and has been structured around the WCTU Programming Team s in-house application development tool CT-AUTO. All software developed by the WCTU Programming Team complies with the Data Protection Act, GCP and all other applicable regulations. The software development process outlined in this SOP will be used for all trials created by the WCTU Programming Team. Software requirements will first be discussed with the Senior Programmer at the grant application stage and before finalising programming costs. All software not developed by the WCTU Programming Team, and therefore not covered by this SOP, should be fully documented and validated. 3. Procedure 3.1 Who? This SOP applies to the WCTU Programming Team and any person working with the programming team in the development of the software. This will usually include the Chief Investigator, Senior Project Manager, Trial Co-ordinator, Statistician and Software Tester/Randomisation Officer. 3.2 When? The software development process begins when an initial request for work is made to the Senior Programmer and is continued until the research is complete. 3.3 How? The procedure is explained in the activity diagram 3.3.1 and the following text. Page 2 of 6
3.3.1 Software Development Process Initial request Project review meeting Change request Create SMR [Senior Programmer Approves SMR] Programmer assigned [PT comments] [Approve SMR] System review meeting [SO Comments] [Approve SMR] FRS Development [PT review FRS] [PT Comments] [SO review FRS] [SO Comments] [FRS approved] [PT Review] System development [PT Comments] [Prototype] [Internal Test] [SO Comments] [Fail] [Fail] [Passed] User acceptance FRS - Functional Requirement Specification SMR - System Modification Request PT - Programming Team SO - System Owner [Passed] Implementation Page 3 of 6
3.3.2 Project Initiation Once funding for a trial has been secured, a senior member of the trial management team should make a request for work by contacting the Senior Programmer. The Senior Programmer will arrange an initial project review meeting to briefly discuss the requirements for the project. The Senior Programmer will allocate the project to one or more Programmers who will then arrange a system review meeting with members of the trial management team. The system review points of discussion should include enrolment/randomisation, CRF design and content, trial and data management, security, timescales (especially urgent requirements), the likely phases of work, mid-term analysis deadlines (e.g. Data Monitoring Committee, Steering Committee etc) and any other relevant information concerning the trial. The identification of the System Owner should be confirmed during the system review. The Trial Coordinator should normally be nominated as the System Owner but if this is not possible either the Senior Project Manager or the Chief Investigator should be nominated. Each system should only have one person as the System Owner. 3.3.3 Requirements and Analysis The Programmer must determine, from discussions with the System Owner and the Statistician the system s data items including the specification of data types, validation constraints, link tables and any processing requirements e.g. disabling of controls, navigation and data searching requirements. Any irregular requests should be addressed to the Senior Programmer. The Programmer will take electronic copies of any documents (CRFs, Reports etc.) that pertain to the planned phase of work and will then utilise CT-AUTO to create the first draft Functional Requirement Specification (FRS) document. The FRS will then be reviewed by the System Owner and the assigned programmer(s). Once the FRS is complete and the Senior Programmer and System Owner are satisfied with the specified requirements, the document will be signed off by both the Senior Programmer and the System Owner. Where possible, each FRS revision should be accompanied with a working prototype. 3.3.4 Design and Development The Programmer will develop the system utilising the current CT-AUTO version (see G12-WCTU-PT Configuring the CT-AUTO Environment), using standard naming conventions (see G08-WCTU-PT - Naming conventions). The Programmer must also follow the standard conventions for creating security roles and tasks (see G09-WCTU-PT - System Security) and must create the standard project folders in the Programming Team s shared folder and in Visual SourceSafe for each new version of the software (see G07-WCTU-PT - File locations). Page 4 of 6
Once development is complete, the Senior Programmer may conduct a code review and/or request a demonstration. 3.3.5 Enrolment and/or Randomisation The Programmer will ensure that the phase of work that includes enrolment and/or randomisation processes should refer to the standard enrolment/randomisation system guidelines (see G04-WCTU-PT - Computerised Enrolment/Randomisation). 3.3.6 Testing The Senior Programmer will identify a WCTU staff member (usually the Randomisation Officer) to carry out the software testing. The Programmer will create a test document and both the Tester and Programmer will conduct the testing cycle (see G03-WCTU-PT Testing). 3.3.7 User Acceptance (UA) Once the software testing is completed the System Owner must review the software and feed back any comments. S/he will sign and date the UA document once satisfied with the software. 3.3.8 Implementation The software will be implemented by the Programmer in accordance to the guideline G05-WCTU-PT Implementation. 3.3.9 Training The System Owner will be expected to become familiar with the software during the development process and subsequently provide training for Data Entry Clerks. Users will be trained to use new application features by the Programming Team as and when they are developed. 3.3.10 Change Management If a change is required after the software has been released (known as a System Modification Request), the System Owner must make a request to the Programming Team via the email address: ctuprogrammingteam@warwick.ac.uk. The Senior Programmer will allocate the System Modification Request (SMR) to a Programmer (usually the Programmer currently assigned to the project), who will create a SMR document (see G01-WCTU-PT - System Modification Request) On completion, the Senior Programmer and the System Owner will review the SMR and sign and date if satisfied with the content. 3.3.11 Problem Reporting (Bugs and Data Cleaning) Sometimes a change request is actually a request to fix a bug or to carry out a data clean. For further instructions on problem reporting and data cleaning see guideline G06-WCTU-PT - Problem/Data Cleaning Reporting Page 5 of 6
3.3.12 Trial Completion The System Owner will notify the Senior Programmer once the data collected for a trial is deemed complete and clean. The Senior Programmer will revoke access to any applications and databases. The Statistician s read-only access is maintained until the Statistician notifies the Senior Programmer to archive the trial data. Archived databases remain on the server but access to all users is removed. 3.3.13 Database Maintenance and Administration WCTU servers are hosted and maintained by the Application Service Hosting Team, a service provided by the University of Warwick Information Technology Services (ITS). Server maintenance and administration tasks (including database backups, failover log shipping, performance and security monitoring) are carried out by ITS. The Senior Programmer periodically reviews the tasks carried out by ITS and requests modifications to the servers as and when required. 3.3.14 List of abbreviations: CRF Case Report Form CT-AUTO WCTU s trial development software FRS Functional Requirements Specification GCP Good Clinical Practice ITS Information Technology Services PT Programming Team RAD Rapid Application Development SO System Owner SOP Standard Operating Procedure SMR System Modification Request UA User Acceptance UP Unified Process WCTU Warwick Clinical Trials Unit Related WCTU-PT Guidelines: 1. G01-WCTU-PT - System Modification Request 2. G02-WCTU-PT - Functional Requirement Specification 3. G03-WCTU-PT - Testing 4. G04-WCTU-PT - Computerised Enrolment/Randomisation 5. G05-WCTU-PT - Implementation 6. G06-WCTU-PT - Problem/Data Cleaning Reporting 7. G07-WCTU-PT - File Locations 8. G08-WCTU-PT - Naming Conventions 9. G09-WCTU-PT - System Security 10. G10-WCTU-PT - Standard Coding List 11. G11-WCTU-PT - Version Control 12. G12-WCTU-PT - Configuring the CT-AUTO Environment These documents can be found alongside SOP 14 on the CTU website: http://www2.warwick.ac.uk/fac/med/research/ctu/advice/intranet/ Page 6 of 6