Posted on Leave a comment

How can Agile work in FDA regulated Software environments

How can Agile work in FDA regulated Software environments?

Some of the biggest myths of Agile software development are:

  • Only one specific way of working
  • Working without documentation
  • Doing iterations with daily standups
  • Working without a plan

The companies which conduct clinical trials maintain standard procedures to the overall Software Development Life Cycle (SDLC) process that will be used in the design, development, testing and operation of software systems developed. For each core product software system, all planned SDLC deliverables and their scaling will be documented in the Validation Plan. Project teams shall document Software change process and applicable deliverables for the system maintenance cycle. For each of the phase prescribed by FDA, we will see how the same applies to Agile way of working. The waterfall style of working can be tweaked to work for agile, the documentation may be maintained in appropriately for the auditors to perform the validation audit.

 

  1. Planning Phase
    Once a software system project has been approved, the planning phase may be initiated. Management shall ensure that all team members have all of the appropriate qualifications and training required to be assigned work on the project. Each software system project shall prepare a Validation Plan. Software systems that are to be released in a phased approach shall be documented as such in the Validation Plan. Each software system requirement shall be detailed in a Requirements Specifications document. The Requirements Specifications should be created using an authorized template. The signature of all project team members shall be documented.

 

In Agile:

  • The Validation plan is a part of sprint level definition of done, and the plan will be produced every sprint
  • The Requirement Specifications document is created by the Product Owner before beginning of every release

 

  1. Development Phase
    The Requirements Specifications may be iteratively reviewed and updated during software system Development Phase. Each product shall document Test Strategy and Test Plan.

    All software source code developed shall be placed under configuration management control.

    The Technical Specifications should be developed during the software system Development Phase. Unit Testing shall be conducted as outlined in the Validation Plan. Code Reviews shall be conducted as outlined in the Validation Plan. A Software Build of the source code shall be delivered to the validation/test team. Test Scripts, reflecting the functionality outlined in the Requirements Specifications shall be written in such a way that they facilitate tracing to the appropriate requirements and shall identify the capturing of objective evidence, when appropriate. Issues, defects & enhancements shall be documented and managed by the project team using a defect tracking system. The project team shall document all decisions

    about all issues, defects and enhancements. A Requirements Traceability Matrix shall be prepared to trace requirements as outlined in the Requirements Specifications to the associated testing.

 

In Agile:

  • Updating requirements specifications iteratively is a part of Sprint level definition of done
  • Test Strategy and Test plan is part of Sprint level definition of done and the same is done every sprint
  • The technical specifications document is produced as a part Sprint level definition of done
  • Unit testing is User Story level definition of done
  • Code reviews are part of Sprint level definition of done
  • Defects are logged in the defect tracking tool as a part of sprint level definition of done
  • Requirements traceability is prepared and updated every sprint as a part of definition of done

 

 

  1. Controlled Testing Phase
    A “Final Feature Complete” Software Build of the source code, with all required functionality implemented, shall be delivered to the validation/test team for Controlled Testing. This software build shall be appropriately labeled. When this software build is deployed to the Controlled Test environment, a code freeze shall go into effect. The Validation Plan, Test Strategy/ Test Plan, Requirements Specifications and Technical Specifications shall be approved prior to the start of Controlled Testing. Unit testing and Code Review documentation shall be completed prior to the start of Controlled Testing. Prior to formal execution in the Controlled Test environment, test scripts shall be reviewed and approved by a Validation Designee different from the Validation Designee who authored these Test Scripts. During Controlled Testing phase, the Test Scripts shall be formally executed in the Controlled Test environment. These Executed Test Scripts shall be accompanied by applicable objective evidence, when required by the test step. All defects shall be communicated and managed by the project team. The project team should document an Impact Assessment to determine the scope of Regression Testing. This Impact Assessment should be documented. When User Acceptance Testing (UAT) is to be conducted for a core product, the UAT may be executed, as outlined in the Validation Plan. The UAT is formally documented by the internal customer(s) and/or user representative(s) prior to release. The results of Controlled Testing shall be documented in a Test Summary Report. At a minimum, the report must account for each planned activity as outlined in the Test Strategy and Test Plan and any deviations or additions to that plan. The report shall be completed at the conclusion of testing or at the conclusion of the validation effort. Test Summary Report may be included/combined within the Validation Summary report. A Release Memo shall be completed prior to formally releasing the software system. The results of validation efforts shall be documented in a Validation Summary Report. At a minimum, the Validation Summary Report must account for each planned activity and/or deliverable as outlined in the Validation Plan and any deviations or additions to that plan.

 

In Agile:

  • Controlled testing is a separate sprint by itself
  • Controlled testing is a part of Release level definition of done
  • All the documents are reviewed and printed out.
  • Automated test scripts can be run as a part of release level definition of done and the report is published.
  • Regression test reports are published
  • UAT may be conducted as a part of release level definition of done
  • Test Summary report, release Memo are published in Control testing sprint.
  • Validation Summary report may also be published in control testing sprint

 

Leave a Reply

Your email address will not be published. Required fields are marked *


The reCAPTCHA verification period has expired. Please reload the page.