36. Software Development Practices – Software Architecture Document (SAD)
Writing software for regulated environments should be a creative discipline and not a creative art form. Guidance from GAMP 5 states that “Each project should define the program coding standards, directory structure standards, and the file naming conventions to be followed. (p. 216)
Whether modified waterfall or various Agile software life cycles are used, it is important that software strategy decisions be documented up front in a product development project, e.g. a zero sprint. In other words it is important to set the engineering context in which code is to be developed to successfully achieve the defined user requirements. The Software Architecture Document (SAD) is the document that records the engineering decisions made to set the product context for the development team. It establishes a vision of the combined application and system architecture that is the target of the project.
In his book Software Architecture for Developers, Simon Brown describes software architecture as “anything and everything related to the significant elements of a software system; from the structure and foundations of the code through to the successful deployment of that code into a live environment.
- Cross-cutting concerns such as logging and exception handling.
- Security; including authentication, authorization and confidentiality of sensitive data.
- Performance, scalability, availability and other quality attributes.
- Audit and other regulatory requirements.
- Real-world constraints of the environment.
- Interoperability/integration with other software systems.
- Operational, support and maintenance requirements.
- Consistency of structure and approach to solving problems/implementing features across the codebase.
- Evaluating that the foundations you’re building will allow you to deliver what you set out to deliver.”
As the project progresses the SAD is updated to reflect new significant decisions made that impact core design values and coding directions and why they were made. The updated SAD can then be used to quickly keep all team members clued in and ramp up new team members into understanding how the project software works and how to become productive in coding it.
The SAD also functions as a training and support resource for product maintenance and enhancements work going forward after commercial release of the software product. Every strategic software product operating in a GXP regulated environment should have an updated Software Architecture Document.
Next Month: Software Development Practices – CASE Tools
Writing software for regulated environments should be a creative discipline and not a creative art form. Guidance from GAMP 5 states that “Each project should define the program coding standards, directory structure standards, and the file naming conventions to be followed. (p. 216)