Feb 142017
 

Many industries rely heavily on a large number of standards, a selection of which are used on each project. There is a perennial problem of managing these so that they are visible within the engineering data environment along with other design artifacts. I wrote previously about some approaches to creating and maintaining traceability to the standards. Here I want to look at the issues around storage, and a possible data architecture.

DOORS Next Generation has moved on again, with real progress being made on useability. The latest release includes a feature that we call ‘components’, and I will be making use of this in my suggested architecture, I will explain what it means as I go along.

I have been prompted to write this, as with many of my articles, by looking directly at the needs of a single customer organization. As with many of those, there are generically applicable good practice approaches. First I will outline the problem: There are a few hundred standards, each of which has an associated guidance document. There are constraints on access such that some individuals are allowed to view the standard, but not the guidance. Each project will need to use a subset of the standards, and in many cases this is a simple question of filtering by system type. The standards also move over time, with new versions being released. Sometimes a new version will need to be included in an in-progress project, and sometimes they will run with the versions that were current at the start of the project.

If we go back 30 years, there would be a list of applicable standards and versions, all of which would be available in print in the library. Formal, controlled copies would be held in a variety of filing cabinets and much of the detail would be, for all practical purposes, invisible to the majority of the project team. More recently, the same documents were available on a server, and sometimes local copies were made – the same basic solution, but with better visibility and searching. I am proposing a very similar solution of having all the standards in the database, and making use of them within the engineering data toolset, but we have no need to take additional copies.

This diagram shows the DNG Project Areas involved. We have one project area for standards, and another for the guidance. This allows us to control the read access separately for the two information types. Within each of those project areas, we have a Component for each standard. This allows us to control the versions and the baselines independently for each standard. The downsides to having separate components are first the the type system is maintained separately for each component, and secondly that finding the right component in the list will involve a lot of scrolling. Type systems can be copied from one component to another, and the eagle-eyed among you will have spotted a third project area with a Catalogue module. The catalogue lists the standards and has a link to both the standard and the guidance module. This also has attributes on which to filter, and attributes for each project to show which standards, at which versions are in use. As each standard comes up for review or revision, a Work Item will link to the appropriate entry in this catalogue.

Each standard or guidance note sits alone in a component, and a separate stream is created for each version, as shown on the left. The catalogue will link to the ‘Latest Version’ stream, but all use in a project will be of a specific version stream.

A standard and its guidance note at each version are grouped as a Configuration in a Global Configuration (GC). When a new project is set up, it will have its own project area, and can be grouped along with all the relevant standards at the correct versions into a Configuration, thus making navigation between the project data and the standards straightforward.

When a standard or guidance note is due for review or revision, a Work Item is created in Rational Team Concert which points to the entry in the catalogue. Streams are created for the new version, and change sets are also created, ready to accept the new work. An additional Global Configuration, not shown in the diagram, exits, consisting of the GC Management configuration and a configuration for each of the the latest version streams of standards and guidance notes pairs. When a new stream is created to update a standard, a corresponding new GC is created and this will be used to temporarily replace the latest version in the GC_Update configuration. When the new version is released, the GC_Update configuration will return to using the Latest Version configuration.

  One Response to “Storing Standards in DNG”

  1. Very interesting article Hazel and I can see applications of this in some of our work if NG can be scaled to that of legacy DOORS

Leave a Reply

%d bloggers like this: