One of the benefits that S1000D provides to the community of technical documentation is the standardization of business process related metadata. Let’s look at the quality assurance cycle for example. Each Data Module (DM) carries the information describing its quality assurance state, which is coded as part of the XML structure. Consequently, the technical data remains independent of software like a Component Content Management System (CCMS.) S1000D identifies three aspects of quality assurance: verification, versioning, and issue type. The following discussion explains these aspects and how they apply to real-world business processes.
S1000D requires a verification process, as part of the standard quality assurance process, be followed for the DM [ASD 2012, Chap 3.7]. A DM may be, “unverified,” “first verified,” or “second verified.” First verification is the manufacuter’s process to assure the information in the DM is technically correct. By changing the quality assurance status from ‘unverified’ to ‘first verified,’ the DM is confirmed as valid. Second verification is an optional process in which the customer confirms the information in first verified DM is correct.
Verification can be performed in two ways, either by proving the information is correct, based on drawings and descriptions from engineers, or by actually testing the information on the product. For instance, a maintenance procedure DM could be tested by actually performing the maintenance procedure on the product. The quality assurance method based on drawings is called, “table top” while the testing method on the product is called, “on object” [ASD 2012, Chap 3.7 p. 5].
Another aspect of quality assurance is keeping track of the DM issues. For this, S1000D introduces two kinds of issue numbers, the two-digit, “inWork number,” which keeps track of internal revisions of the DM until it is released, and the official three-digit, “issueNumber,” which keeps track of the official revision numbers [ASD 2012, Chap 184.108.40.206 p. 8]. Table 1 shows the sample life cycle of a DM.
Table 1 Sample Life Cycle of a DM
|4||001||00||new||firstVerification secondVerification||tabtop onobject|
|7||002||00||changed||firstVerification secondVerification||tabtop tabtop|
At the beginning of the process, the technical author creates a first version of the DM. It is still ‘unverified’ and the issueNumber is ‘000’ since it has never been released. It is the first internal version, so the inWork number is ‘01.’ After finishing the work, the author sends the DM in issue ‘000:01’ to the responsible engineer for review. In the example, the engineer found an error in the content of the DM, so the author corrected the content and produced issue ‘000:02’ of the DM. This issue of the DM was verified by the engineer to be correct using the table top method, which leads to issue ‘000:03’ of the DM and is in quality assurance status ‘first verified.’ The DM is then sent to the customer. The customer verifies the content of the DM to be correct using the on object method. As a result, the DM is officially released in quality assurance status ‘first verified’ and ‘second verified.’ The official issueNumber is increased by one to ‘001’ and the inWork number is being reset to ‘00’ (row 4 in Table 1.)
After some time passes, the manufacturer discovers a cleaning agent being used in the maintenance procedure damages the surface of the component in the long run; as a result, the DM must be revised. The author creates the first internal revision of the DM and sends version ‘001:01’ to the engineer, who approves it using the table top method. The version ‘001:02’ in quality assurance status ‘first verified’ is sent to the customer, who approves it using the table top method. There is no need to test the procedure since only the cleaning agent has been exchanged. The DM is officially released and issueNumber is increased by one to ‘002’ and the inWork number is reset to ‘00’ again (row 7 in Table 1.)
The “issueType” keeps track of the revision type. It gives an indication on what parts of the DM have been changed and to what extent. This information is typically used in the list of DM or the list of highlights as part of the “front matter” of a publication, which can be produced automatically based on the information in the DM. Maintenance organizations may also use this information for their planning purposes with regards to the creation of new, or the adaption of, existing task cards. Table 2 shows the available values with their corresponding meaning.
Table 2 Available Issue Types
|new||The information is new. Has to be used for all DM/PM with issueNumber 000 and for issueNumber 001 with inWork 00|
|changed||The information has been changed in some places and you would expect to see single change marks in the content|
|revised||The whole content of the DM/PM is seen as being changed and you would not expect to see single change marks|
|status||Only status information has been changed, not the technical content|
|deleted||The information contained in the DM/PM is not applicable to the project anymore|
|rinstate-changed||Same as ‘changed’, but the previous issue was ‘deleted’|
|rinstate-revised||Same as ‘revised’, but the previous issue was ‘deleted’|
|rinstate-status||Same as ‘status’, but the previous issue was ‘deleted’|
Figure 1 shows the parts in the XML of the DM, where the QA information is stored:
Figure 1 QA Information in the DM XML
ASD. 2012. S1000D Issue 4.1. International specification for technical publications using a common source database. Brussels: AeroSpace and Defence Industries Association of Europe.