As Stuart notes, based on our last meeting, there seemed to be a consensus around defining the necessary attributes of documentation, irrespective of particular formats. Regarding engineering activities per se, the TC charter focuses heavily, but not exclusively, on development activities associated with documentation. However, to the extent that we define specific artifacts for privacy processes or services (Deliverable 3: "...envelope design artifacts for privacy processes or services"), these should be associated with Deliverable 1: "...software tools...to aid in producing documentation..."). If so, a mapping needs to be made between the design artifacts and the documentation. Presumably checklists having specified properties could serve as one method (format) to do this. Perhaps we need to reach agreement on what the charter language about "envelope design artifacts" means in the context of the other deliverables.- A LIST OF DELIVERABLES AND PROJECTED COMPLETION DATES
The key deliverables of the OASIS Privacy by Design Documentation for Software Engineers is developing a documentation standard that ensures software developers can integrate PbD principles into software analysis and design documentation, such as, but not limited to, functional use case diagrams for software products and services, and comprehensive misuse cases. Estimated completion date is 12 - 18 months after the formation of this TC. - PbD documentation for software engineers: Define a standard specification for software tools that engineers can use to aid in producing documentation and to show compliance with the PbD principles, and privacy regulations, throughout the entire software development life cycle.
- Develop misuse cases that deal with the handling of personally identifiable data. The misuse cases should focus on potential privacy and security violations.
- Develop envelope design artifacts for privacy processes or services that can be integrated into documentation such as scenario diagrams.
- Develop procedures to be used by internal independent reviewers in order to conduct reviews of all analysis and design documents, e.g. use cases, misuse cases, interface design, class diagrams, scenario diagrams etc., for explicit adherence to PbD guidelines.
On Feb 11, 2014, at 4:14 PM, Shapiro, Stuart S. wrote:
I wasn't aware that we were trying to accomplish the first one. Inevitably, we have to refer to life cycle activities to situate various types of documentation, but I don't think we're trying to specify privacy engineering activities per se. Reaching back to
our last telecon, I thought we were trying to come up with a normative specification for privacy documentation that is agnostic with respect to the specific notation or representational scheme. If so, this addresses the concern regarding template/format preferences,
as we should not be specifying templates and formats (though we can offer examples) but rather attributes or properties that indicate that a particular notation has the capacity to capture and communicate the necessary information.
Stuart
Hei PbD-SE-ers.
The latest draft of the TC specification seems to be trying to accomplish two separate things. One – To provide guidance on privacy engineering activities to complete throughout
the product development lifecycle. Two – To provide guidance on templates/formats for particular artifacts/evidence of good practices for privacy engineering. I wonder if these should be separated into two deliverables? One argument is that the first deliverable
objective could be specified in a normative way, based on leading and best practices. However, the second deliverable objective is elusive because of personal and organizational preferences for the templates/formats for such artifacts/evidence. In fact, even
within on particular template/format there can be broad differences in deployment/usage.
Lastly, in regards to the first deliverable objective, we do not yet have what I think is a useful arrangement for conveying the guidance on privacy engineering activities. I have
a “privacy architect” colleague Ian Oliver who has written public blogs about how the aviation and medical fields have leveraged “checklists” to reduce risk within their fields (i.e., pilot checklist and surgical team checklists). The latter has been documented
extensively because of the significant reductions in surgical theatre mishaps and post-surgery morbidity. Dr. Oliver has applied surgical checklist best practices to privacy engineering in the form of development team checklists. Whether you are using waterfall
PDLC or agile PDLC forms, you have the same three-phases around a milestone or sprint/release. You have the Pre-Event, In-Event and Post-Event stages around the milestone. The purpose of industry checklists is two-fold; one – to make sure all the team involved
in the event are aware of their roles and are prepared for the event and, two – to make sure proper activities are conducted and adequate evidence of accountability is recorded of completion of those activities.
Here is a good overview of how checklists are applied in the medical/surgical context, from a publication of the World Health Organization.http://www.who.int/patientsafety/safesurgery/ss_checklist/en/
My suggestion is that OASIS PbD-SE team look at using the checklist approach to formatting the privacy engineering activities that need to be addressed during the PDLC, by creating
such a checklist for the basic milestones we identify.
Frank/
|