This content has been marked as final. Show 2 replies
Rather than attempting to use Cobol (or any programming language's translation) as the "source" for OPM rules, the preferred approach is to use the requirements or original policy documents as the definitive "source" for capturing policies in OPM documents. Of course, many orgs have moved well beyond keeping their requirements or other docs in sync with the actual code, so they now view the code as "the rules". The difficulty in creating and maintaining traceability to "source code rules" from OPA rules will depend heavily on how well the source code is documented and whether it is already organized in rule-centric components, functions or other constructs. For example, lines of code that compare current values of variables to other values, constants or function results will have little meaning without the context of why such a check is being made in the code. Whereas, individual functions which validate a specific requirement or policy may map to OPM rules in a more direct manner and improve traceability.
One recommendation is to first reverse translate code into a document containing the rules / requirements enforced by the code (i.e. ask why does this code exist and do what it does). Once that document is agreed upon, then utilize that document as the source document for OPA rules. Of course, writing the requirements in the OPM "conclusion if conditions" style will greatly speed the step of writing the actual OPM rules.
I think you will find the hard part to be documenting the link to/from source code with any well organized natural language document (unless, as mentioned, the code is already organized to align with policies / requirements). The traceability to/from OPM documents to other documents or files can be accomplished with any of the MSWord features including hyperlinks, bookmarks, attached comments, etc.