Process for the DDI 4 
Development Project
Version 0.3 – 28 April 2014

I. Overview

This document describes the work process and organization for managing the DDI 4 development project. It is intended to be a living document, which may be changed as we work through the process. However, it is felt that having a documented and agreed process is important so that new staff (especially a new project manager) can more easily "ramp up" to participate in the process.

This document does not replace other documents created to help members of the various working teams perform their jobs within this process.

II. Work Process

The diagram below shows the high-level work flow. More detail can be found in other documents regarding the specific activities of the teams performing the functions shown here.

Figure 1

1) The Content Modelling Teams will either create views (that reflect common use cases and user stories) or create portions of the core objects in the library (objects which are needed by many views). The Content Modelers work with a Data Modeler to scope and produce a draft model.

 2) The draft model is critiqued by the Data Modeling Team. Corrections are made by both teams working together, until a final approved version is realized. This process will be the same for portions of the Library and for the design of Functional Views.

The following issues should be addressed in the QA/Review process at this stage:

• Completeness of models
• Existence of documentation at Package Level and Object Level
• Consistency of modeling with other parts of the Model Library

When a final version of the model is agreed, the status of the model goes to "Final". The Data Modelers are responsible for assembling the finalized work of the Content Teams into a coherent Model Library.

3) Once approved, the Documentation Team will get a Docbook file with the documentation as programmatically exported from Drupal, and the Production Team will get final versions of the models and views as XMI; the Data Modeling Team will produce diagrams going to both the Production and Documentation Teams, as needed.

The Production and Documentation Teams will then work to programmatically produce the needed outputs:

The Production and Documentation Teams will need to work in a highly collaborative fashion in order to assure that work products stay in sync. The Documentation Team will need to work with the Content Modelers to ensure that the edited end product meets the content modelers' expectations.

4) When finalized, these outputs will go through a second round of QA/Review, conducted by the Technical Committee, assisted by others as needed.

This review process will check:

• Completeness and consistency of the deliverable package
• Alignment of deliverables with the release strategy of the Alliance
• Alignment with other standards
• Compliance with design principles
• Compliance with syntax bindings
• Usefulness of the documentation

At this stage, the work products are prepared by Technical Committee for circulation within the DDI Alliance for internal approval, and eventual publication for external review and approval.
The Technical Committee and the Tools Development Team function in a support capacity throughout the entire process in conjunction with the working teams.

III. Organization and Roles of Teams

There are several different teams and individuals involved in the DDI 4 development project. These are shown in Figure 2. In this section we describe the role of the different teams involved in Project. We do not discuss the functions of the DDI Alliance Director, or the Scientific or Executive Boards. These are included only to show how the DDI 4 development project teams fit into the overall organization of the Alliance.

Figure 2

Only the Technical Committee is a standing team – other teams are organized for the duration of the DDI 4 development project. The Technical Committee has several functions:

• Supporting the Project Manager in identifying solutions for issues found by the working teams
• Participating in each of the working teams, to help provide coordination and oversight
• Participating in the QA/Reviews, at each point in the process
• Reporting issues to the Project Manager as these emerge

The Project Manager runs the overall process. Status and issues identified by any of the teams would be reported to the Project Manager, who coordinates the overall process.

The Content Modeling Teams work with a Data Modeler and a Technical Committee member (could be the same person) to create the models making up the Object Library, and to develop Functional Views. They are also responsible for all documentation at the Object level and the View level. 

The Data Modeling Team is responsible for the technical modeling and integration of the Objects into the Object Library, and the review and integration of Functional Views into the model. They are also responsible for producing diagrams for use in all documentation deliverables.

The Documentation Team is responsible for taking the diagrams produced by the Data Modelers and the Docbook export from Drupal, and editing and assembling these into the needed documentation outputs. 

The Production Team runs transformations on approved outputs to create XML schemas and RDF ontologies, and to assist the documentation team to produce a complete output package for the final QA/Review step.

The Tools Development Team is responsible for the development and maintenance of the technology tools used by the other project teams, such as Drupal, format-specific transformations, and the overall tools environment.

IV. Expectations for Project Work

Working Style

The majority of the project work will be undertaken via virtual team meetings. The expectation is that each group will meet every two weeks during the lifetime of the team.. Virtual meetings are conducted using GoToMeeting.

There will also be some face-to-face meetings called Sprints. Sprints are intensive focused workshops. Where possible, these will be planned to take place in the vicinity of conference or workshops that project team members are likely to attend (for example IASSIST).

In order to ensure a transparent working process, team communications are conducted using the collaboration platform (the Confluence Wiki). All discussions within the teams and inter-team communication should be done through the wiki. All working documents should appear here. For each team meeting, minutes should be kept and posted on the Wiki. The use of personal e-mail is strongly discouraged, as this leads to a lack of transparency.

Skills

Each team requires a different set of skills. 

Content Modelers are expected to have expertise relating to particular use cases/functional views – for example, the content modelers designing the simple instrument model would be expected to have expert knowledge of how questionnaires are structured and used.

Data modelers should be familiar with UML tools and modeling best practices for object modeling. The tool being used for this project is Enterprise Architect.

The Documentation Team is composed of people with strong editorial skills and a familiarity with the different types of users who will be reading the documentation.

The Production Team is made up of people who understand the technology tools and the work products – XML Schema and RDF – which they will be creating.

The Tools Development Team is made up of software engineers who are familiar with the tools and technologies used for production, such as Drupal, Enterprise Architect, Docbook, XMI, RDF, XSLT, etc.

Outstanding issues

1. At what point is syntax-specific documentation produced? How is it stored and managed?