A standard operating procedure can help the validation professional define the development environment and the nature of the work being performed. Although this SOP must be written and maintained outside of the scope of the user and functional requirements for a project, it must be appropriate to the project. For example, if a developer is required to write C++ code for a certain project, then the SOP must contain the method by which the developer obtains existing code and libraries, the software program versions and patch levels, the coding standards by which code will be found accepted, and all other methodology by which the design phase will operate. A complete SOP is the prefect presentation for the CFR issues and industry methodologies that will help guide developers to create project deliverables that are reliable and traceable. Here's an example of good material to consider when writing a development SOPs:

• Approved Software Tools (with names, versions and patches)
• Use of Code Control Tool
• Internal Program Documentation (how to write comments, etc.)
• Coding Style
• Naming Conventions
• Use of Global Variables and Constants
• Optimizing Code for Reuse
• Error Handling
• Proper Code Blocking, Indentation and Loop Control

Developers, although probably the most boring part of your job, writing clear and accurate design documents is the key to presenting your work clearly to your quality department. Start by creating a design template for each type of code object you intend to deliver. Here's a quick example of what J&R Consulting uses for the structure of our java class designs:

• Class Name
• Name Space (package)
• Extends
• Implements
• Description
• Use Cases
• Properties
• Constructors
• Methods

• Name
• Description
• Parameters
• Processing
• Returns

• Events

Although this format will be insufficient for certain implementations, it covers 80% of the non-GUI objects we write. Remember, this is just a template, and can be modified as needed.

Assuming that you are writing the design after the code has been written (although a poor practice in my opinion, we see this frequently even written in corporate methodologies), never include actual code. Code logic should always be written in paragraphs with proper grammar and sentence structure. Do not be too concerned with describing superficial methods. Instead of writing three or four sentences describing how a loop variable is incremented, simply start a new paragraph by saying something like, "For each record in the cursor do the following." Remember that humans are intelligent and do not desire the minutiae that computers require to understand a concept.

Although the divide between developers and validation professionals seems large, precise standard operating procedures and clear design documents can be used to present knowledge and work in a manner that is suitable for spanning the communication gap.