For a long time, the V-model was considered the standard procedure for software development projects in GxP-regulated environments such as the pharmaceutical or medical device industry. With the increasing spread of agile development methods, however, the question also arises here of how the advantages of an agile approach can be successfully combined with the regulatory requirements of the GxP guidelines.

Be it the migration to S/4HANA, the use of laboratory systems or automation in the production environment. The development of software components in the life science sector is almost always subject to GxP guidelines, which binding expectations with regard to diligence during development as well as traceability over the entire life cycle from the requirements to the final test in operation. In order to meet the resulting validation obligations, the V-model is established standard procedure.

Sequential procedure in the V-model

In a sequential procedure, all requirements are first specified in a top-down process and subsequently implemented. In a separate test phase, the software components are then verified bottom-up from development testing to functional testing to integrative acceptance testing. There is a documentation obligation for each of these steps, which is intended to ensure continuous traceability throughout the entire development process. A superordinated risk management at the requirements level ensures that only the GxP-relevant parts of the system are considered.

The right development process for every project

For software development projects with known user requirements as well as a clearly defined range of functionality, such as those frequently encountered in the pharmaceutical and medical technology industries to date, this approach can be quite effective. However, if one encounters project environments in which the shortest possible time-to-market is important, in which the requirements are not yet clearly defined at the beginning of the project or can change continuously, this sequential approach quickly reaches its limits. Here, agile methods that support the early provision and iterative further development of functional elements offer clear advantages.

Faster feedback thanks to the agile approach

In contrast to the strictly sequential procedure in the waterfall or V-model, in the agile procedure, the overall scope is broken down into short-cycle, successive sprints, at the end of each of which finished software components are available. This results in clear advantages with regard to the earlier availability of executable (partial) programs. This enables the client or user to receive quicker feedback on the implementation of individual requirements and, if necessary, allows new requirements to be added to the scope throughout the project.

However, in order to use this process model successfully in GxP-compliant environments, additional validation steps in the sense of breakpoints must be provided in order not to lose sight of the necessary documentation and approvals. Corresponding extensions of the existing procedure will be presented below.

Continuous documentation as a basis for a GxP-compliant agile approach

The agile process model for GxP environments focuses on the continuous maintenance of the documentation. Instead of specifying all requirements first in a separate analysis phase, the entire V-model process of analysis, implementation and testing is run through in each sprint cycle – and the drafts of the documentation are successively expanded for the requirements included in the sprint. As a result, the required documents, such as the User Requirements Specification or the Functional Specification, but also tests, are available faster than with the conventional procedure. This gives the validator the opportunity to check again and again at an early stage whether the type of documentation meets the requirements and to intervene in a controlling manner. This reduces the susceptibility to errors and increases the quality of the documentation. For a productive go-live, the drafts created during development are frozen into formal documents and finally run through the formal tests, so that in the end, there is complete validation documentation for the release. The next release can then be developed using the same agile approach.

For the development teams, this form of continuous documentation may result in more documentation work at the end of the day. However, the documentation to be done is better integrated into the development process and is therefore usually perceived as more acceptable.

Gradual expansion of the project scope

One risk of this agile approach is the constant expansion of the project scope. In contrast to the classic approach, in which the requirements defined at the beginning of the project are implemented as a whole, and therefore hardly any scope creep can occur, the agile approach with frequent intermediate releases invites the requirements to be constantly adapted and expanded in the spirit of a moving target. This can be very profitable, especially for projects with an exploratory character, but on the one hand, it bears the risk that projects may get out of hand in terms of costs and time. On the other hand, there may be a gradual shift in GxP relevance, e.g. a previously uncritical process suddenly becomes GxP-relevant due to additional implementations. This may result in the form of documentation no longer meeting the requirements for validation.

Success factors for the introduction of agile methods in regulated environments

In order to effectively counter the risks mentioned above, the following tips should be observed in an agile approach:

• Even if the implementation of individual functional elements takes place gradually and iteratively as part of an agile approach, it is still advisable to develop a "big picture" of the planned overall system at an early stage and to define the boundaries of the architecture. Otherwise, there is a risk that the entire system will collapse in response to the ever-increasing demands.
• In order to give the development teams enough time for implementation in addition to documentation obligations and tests, the sprints should not be too short-cycled, but should last at least two to four weeks. In addition, regular demos should give the client and other stakeholders the opportunity to provide feedback on the way the project is implemented and to make adjustments to the requirements if necessary.
• For productive go-lives, the release phases of the planned system should be coordinated with those of other connected systems to avoid disruptions. I.e. these go-lives between the connected systems should be coordinated in terms of timing and functionality.
• Fixed points in time within the sprint cycle at which documentation updates have to be provided can help to establish the necessary documentation discipline. Enforcement should be carried out in close cooperation between the sprint master and the validator.

Conclusion: Growing acceptance of agile methods

Agile approaches also offer advantages in certain project environments for software projects in the pharmaceutical and medical device industry – especially in the form of faster feedback and step-by-step implementation of individual software components. However, reduced documentation effort is not one of them. Nevertheless, an efficient and at the same time GxP-compliant validation can also be implemented with agile methods if the appropriate precautions are taken.

The fact that this combination could gain further importance in the future is also shown by the second version of the GAMP 5© guide – the standard set of rules for the validation of computer-aided systems in the pharmaceutical industry – which was published at the end of 2022. For the first time, it recommends the use of agile software development methods in addition to the V-model. In addition, definition of acceptance criteria for agile development methods are also planned in the concept paper on the revision of Annex 11^[1] published jointly by EMA and PIC/S.

As a result, the V-model is no longer the only way for validation procedures. What this means for the majority of software projects in this area remains to be seen. In any case, it will be worthwhile in the future to critically question which approach is best suited for a project.

^[1] https://www.ema.europa.eu/en/documents/regulatory-procedural-guideline/concept-paper-revision-annex-11-guidelines-good-manufacturing-practice-medicinal-products_en.pdf