How does model generated documentation fit into a regulated industry document lifecycle required as part of GaMP? Traditionally, regulated industry manually develops its automation design specifications. These word or excel documents are then maintained throughout the lifecycle of the project.
A typical traditional document lifecycle management spreadsheet might look like this:
This system is easy to understand, easy to project manage and implement, and it is easy to implement document changes. It is easy to scale up resources for large project execution. The documents are easy to review. The downside is, it is slow, labour intensive and in some cases not as good at capturing the design functionality, as a reviewer has to imagine how the system might work without having recourse to an interactive model.
Is it possible to have the best of both worlds and use a model to generate these document throughout the lifecycle? Not really!!
It depends on what is acceptable to your document design lifecycle. A model can capture and export the design specification for you but probably in a new format that people may have to adapt to. What happens when you want to change the design mid-project? Do you have to modify the model and export the design document again? Or do you forget about the model and start to manually edit the design documents? This is the issue at the crux of the use of model generated documentation in regulated industry design lifecycle projects.
There is no easy answer to this but there are parallels with the use of 3D models in modern engineering / architecture design; more and more, the models are being kept ‘live’ and up to date throughout the lifecycle as the master source of requirements. They can end up being a record or ‘as built’ of the final delivered project.
Similarly in modern ‘Agile’ high level software design (for example a new website), some methodologies have a ‘live’ prototype which is maintained as a living record of design requirements. With more and more software projects going ‘Agile’ it can be helpful to have a model to figure out what is achievable in each of the sprints, and how they affect the big picture.
A study on Alternative Software development models and methods in GxP Environments highlighted some concerns for the Model driven Architecture (or prototyping as we call it) approach regarding lifecycle documents.
(by ISAP GMAP D_A_C_H SIG ASDMM reprinted with permission from Pharmaceutical Engineering Jan2012 Vol32 No.1)
Conclusion
There is a place for modelling / prototyping during requirements capture, but for now, the prototype will just form the basis of the initial design document which will subsequently be subsumed into traditional document control. No project wants to allocate resources to keeping both a model and separately generated documentation in sync all the time!
If companies really wish to implement an ‘Agile’ lifecycle in order to benefit from faster cheaper project execution and better change management, they will have to move away from the traditional document lifecycle and move more towards model driven architecture.
See Spike in action or try it yourself, no sign up or login required.