Автоматизация выпуска комплектов документации для группы подобных изделий

, ,

«ЦНИИ «Электроприбор», Санкт-Петербург

Разработка технической документации подразумевает четкое выделение предмета документирования и его границ. Предметом документирования может быть, например, отдельно взятый гироскоп или навигационный комплекс целиком, программное обеспечение к нему, не стандартная комплектация поставки комплекса или систем определенного типа и т. п.

У предмета документирования должны быть четкие обозначения, в том числе:

·  официальное полное наименование;

·  номер версии, дата выпуска или другие данные, идентифицирующие конкретное состояние предмета документирования, которое будет зафиксировано в документации.

В идеале предмет должен быть защищен от изменений во время документирования. На практике добиться этого, особенно на развивающихся предприятиях, обычно не возможно. Во всяком случае, процесс документирования должен быть организован таким образом, чтобы любое изменение в изделие не приводило бы к перевыпуску всей документации к нему.

Так же, для модификаций или версий, одного и того же изделия сопроводительная документация будет во многом совпадать, то же и для изделий изготовляющихся партиями. При этом документация может быть различной в зависимости и от заказчика. Но эти различия ¾ комплектность и подробность поставляемого комплекта документов, фактически, один комплект, целиком включает в себя другой. В итоге формировать комплект заново для каждой модификации/партии нецелесообразно.

НЕ нашли? Не то? Что вы ищете?

Проблема, описанная выше, решается путем автоматизации процессов разработки технической документации. Актуальным в настоящее время является применение модульного принципа. Суть принципа в том, что он позволяет разработчикам создавать составные документы из многократно используемых фрагментов (модулей данных), хранящихся в единой базе данных. База данных, вне зависимости от ее технической реализации содержит, все модули данных, которые могут быть включены в разрабатываемые документы. Объем модуля данных определяется его предполагаемой функцией, фрагментом может быть целая глава, а может одна таблица. Обычно от модулей данных, несущих одну функцию, требуют единообразной структуры. Для каждого модуля в единой базе данных должна храниться ровно одна копия (обычно, справедливо до уровня проекта в единой базе данных). Модуль данных имеет уникальный идентификатор (код модуля данных). В конкретной статье рассматривается единая база данных в которой модули данных представляют из себя XML-файлы.

Эффективность подхода в первую очередь зависит от максимального уровня многократного использования компонентов документа. Для увеличения процента заимствования в модули данных вводится динамические объекты. Эти объекты – XML-теги имеющие вариативность значений в зависимости от набора заранее известных критериев.

Основные критерии:

·  Заказчик;

·  Комплектность;

·  Модификация.

В итоге, выходной документ (поставляемый комплект документов) можно профилировать (задавать применяемость) по необходимости.

Таким образом, применяемостью называется автоматический отсев\добавление\изменений фрагментов модуля данных по заданным критериям при формировании выходного документа.

Пример формирования руководства по приложениям, имеющим параллельные версии для разных аппаратных платформ и операционных систем, приведен на Рисунке 1.

Рисунок 1

Список использованной литературы

AC 1.1.S1000DR-2011 Международная спецификация на технические публикации, выполненная на основе общей базы данных (сокращенное название — S1000D);