SDLC Methodologies and Validation

Transcription

1 SDLC Methodologies and Validation Presented by: Pamela Campbell Lead Consultant, Compliance Services DataCeutics, Inc. Presented for: DIA Annual Meeting, June 2004 Session 330 VA Validation, EDM, IT June 16, :30am

2 Who We Are. The Leader in Information Technology Support and Services for the Clinical Research Environment Headquartered in Pottstown, PA Solutions include Services and Software Products Three Business Lines: Clinical Systems Services (CSS) Clinical Reporting Services (CRS) Computer Systems Compliance Services (CSCS) Expert Consultants

3 Our Computer Systems Compliance Philosophy... Computer Systems must be planned, designed, developed, tested, installed, operated, maintained, and archived according to regulations and acceptable industry and company standards

4 Agenda Validation The Phases of a Project Project Conception System Study Programming Acceptance Operational Maintenance Decommission Conclusions

5 Validation Validation The establishing of documented evidence through defined tests & challenges, that a system or process meets design criteria & that adequate provisions have been established to keep it in a state of control so it will produce a product that meets predetermined specifications and quality attributes. When done correctly validation creates sustainable, repeatable success! When done incorrectly validation becomes a burden that hinders business and results in audit findings and Form 483s.

6 Phases of a Project Project Management Conception Define Scope SDLC Validation Plan Validation System Study (Design) Programming Acceptance Operational Maintenance User / Function Requirements Design Code Unit Testing System and Integration Performance and User Acceptance Testing Installation Release User / Function Requirements Specification System Design Specification Vendor and Risk Assessments Code Reviews Unit Test Plan, Scripts, Matrix, Report System and Integration Plan, Scripts, Matrix, Report PQ/UAT Test Plan, Scripts, Matrix, Report IQ/OQ Plan, Execution, IQ/OQ Report, Validation Report Change Control, Backup Functioning under SOPs for change and Recovery, Archiving control, etc.

7 Project Conception Critical function definition of scope Both the project scope and the scope of the validation must be defined in this phase! Both should be defined in the validation plan. Scope creep will kill a project! Determine what is not covered by the project, examples: Network qualification Data Center qualification

8 System Study Chosen methodology for designing system should be spelled out in a SDLC SOP or the validation plan. Validation and project deliverables: User & Functional Requirement Specifications Remember requirements must be testable! Don t forget 21 CFR Part 11 & Predicate Rules! System Design Specification edms purchased system describe how the system is to be installed, configured, and programmed Matrix from UFRS to Design For Vendor systems Vendor Assessment! Risk Assessment

9 Development Methodologies (System Study) Waterfall Whirlpools Incremental / Spiral Prototyping Whichever is selected it must be documented in the validation plan and any matching SOPs!

10 Waterfall Conception Requirements Design Programming Code Review Unit Test SIT UAT Installation Operation Maintenance

11 Waterfall - issues Studies show waterfall method is 90% project management and 10% what is to be done and how to do it. Each phase feeds into the next and therefore there is no feedback creating a gap between end user and developers. No way to go back and fix mistakes. Very expensive to use. Takes a long time.

12 Whirlpool Conception Initial Iteration Conception Requirements Design Programming Code Review Unit Test SIT UAT Installation Operation Verification Loop Reconcile system to expectations Maintenance

13 Whirlpool Basics More interaction between initiators and staff implementing requirements. Verification Loop second iteration to remove bugs found in testing. Loop to reconcile system to user expectations was the correct system built? Steps move and shift to save time and money when answering this question.

14 Whirlpool Difficulties Very complex methodology. Difficult to manage due to number of iterations. Hand off to maintenance tends to be shaky. Still gaps between - What and How Developers present system instead of users presenting requirements.

15 Incremental / Spiral Conception Reconciliation Requirements Requirements Reconciliation Reconciliation Design Requirements Design Verification Reconciliation Programming Verification Design Code Review Programming Unit Test Verification Code Integration Review Unit Test Programming Integration SIT Code Review Unit Test UAT SIT Integration UAT Installation SIT Operations Installation& UAT Maintenance Operations & Reconciliation Maintenance Installation Reconciliation Operations & Maintenance Reconciliation

16 Incremental / Spiral Perform the waterfall in sections. Several mini projects are undertaken to implement the goal. Gap between what and how is narrowed. Requirements and Design are closely related. Clean Interfaces must be maintained between the modules.

17 Prototyping Conception Requirements Design Programming Code Review Prototyping Each phase feed into the next, But there is feedback among the first three phases Unit Test SIT UAT Installation Operation Maintenance

18 Prototyping Prototyping is a process that permits the developer to create a model or mock-up of the system to be built. It must be decided in advance if the prototype is a throwaway or to be kept as the initial version of the system. If the prototype is the initial version of the system the code must be placed under configuration management. The choice must be documented in the validation plan.

19 Prototyping Prototyping begins with some type of protosystem or model. Then an initial set of requirements is created. The model is then updated with modifications. A matching update of the requirements is made. This process is repeated until the requirements are finalized.

20 Prototyping Issues Keeping code under control. Customer does not realize the prototype is not a working supportable code model and does not understand additional time required to go from prototype to deliverable system. An inappropriate operating system or programming language may have been used to create the model and everything must be reworked. Rules must be defined before prototyping begins! Validation Plan Prototyping SOP

21 Programming Validation and Project Deliverables Code Code walk throughs Memos Responses Unit Testing Plan (Matrix from UFRS to Design to Scripts) Scripts Report of results (include resolutions to errors) System and Integration testing Plan (Matrix from UFRS to Design to Scripts) Scripts Report of results (include resolutions to errors)

22 Programming Code should be written in a controlled manner. Standards help promote the writing of maintainable code. Code / configuration management Permits the easy backing out of changes. Allows for repeatability. Metrics. Code walk throughs! Verify standards are being followed. Match code to what is being stored and tracked in Code Management tools.

23 Programming Unit Testing Test the individual modules. Do the requirements track to a module or will an SOP need to be written to meet a requirement? Users should be told as soon as possible. System and Integration Testing When modules interface with each other and the target Operating System do they continue to work? Again do requirements track?

24 Acceptance Validation and Project Deliverables IQ/OQ for testing Installation and Operation Qualification for Test System Execution Report of Results Performance Qualification / User Acceptance Testing Plan Scripts Execution of scripts Resolution of non-conformances Traceability Matrix Report of results

25 Acceptance Performance Testing This is only useful if performance requirements were defined so that they are measurable. Internet speed can not be meaningfully tested! No one company has end to end control of an Internet connection. Performance testing should be executed on manufacturing systems and laboratory systems that function in real-time! Other items such as scanners for edms may also require testing for data transfer tolerances.

26 Acceptance User Acceptance Testing Scripts should mimic actual plan use of the system. If instruments or devices will be connected and transferring data, check those interfaces! Remember to do all those security tests for 21 CFR Part 11! This is critical for edms that will use electronic signatures. If a SOP will be used for missing functionality make sure this is documented in the PQ/UAT Traceability Matrix and PQ/UAT Report.

27 Operational Validation and Project Deliverables Installation and Operation Qualification for Production System Test items such as backup and physical security if not tested in PQ/UAT Execution Report of Results Validation Report Deviations from the Validation Plan Any non-conformances from testing - include resolution

28 Maintenance The system is now in a controlled, successfully functioning state, how will you keep it there? SOPs Change Control Validation and Re-validation Security Anti-Virus Disaster Recovery Business Continuity User Management Auditing

29 Decommission When the system becomes obsolete, how will the data from it be stored to match the data retention policy? Migrate information to another system? Mothball the system? Retire the system but keep it running?

30 Other things to worry about... Security Do your backups really work? Test them! Disaster Recovery (did you test that plan?) Network Qualification Data Center Qualification Training in the new application On going training for new hires

31 Training Make sure your developers data center staff receives validation training! Also help your staff understand the end product that actually brings in the money that pays their salary. Give them a reason to take pride in the validation and compliance process.

32 Conclusions and Summary Validation need not be a burden. Incorporate it into daily operations! Results Functioning systems Supportable systems Repeatable performance Improved business processes Fewer audit findings!

33 References DeGrace, P. & Stahl, L. H. (1990). Wicked Problems, Righteous Solutions: A Catalogue of Modern Software Engineering Paradigms. Englewood Cliffs, NJ: Yourdon Press Computing Series. Pressman, R. S., (1993). A Manager s Guide to Software Engineering. New York: McGraw- Hill. The Validation Dictionary. Royal Palm Beach, FL: Institute of Validation Technology.