• новости, помощь наших специалистов
• применение ГОСТ 19, применение ГОСТ34
• образцы документов, публикации
• критика, о жизни, консультации в форуме
• книга об AuthorIT

Автоматизация разработки технической документации. Часть I

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

В крупных компаниях в процессе разработки технической документации задействовано, как правило, значительное число специалистов различных подразделений. В мелких и средних компаниях техническая документация «составляется» узким кругом лиц, именующих себя техническими писателями - представителями профессии, по сей день не нашедшей себе достойного места в общероссийском классификаторе.

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

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

Целями настоящей статьи являются:

• повышение управляемости жизненного цикла технической документации;
• снижение трудоемкости и ресурсоемкости процессов жизненного цикла технической документации.

Задачи статьи:

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

Разработка технической документации - современная ситуация

Техническая документация: назначение и об отношение к ней

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

• во избежание ответственности перед Законом - на авиажаргоне такой подход называется «прикрытием задней полусферы»;
• для исключения возможных формальных претензий со стороны Заказчика.

Указанный подход обеспечивает все предпосылки к разработке технической документации высочайшего качества. Ясно, что нести судебную ответственность и выплачивать денежную компенсацию за гибель животного идиотке, выстиравшей свою киску в стиральной машине и высушившей любимицу в микроволновой печи, - дураков нет. Требуются лишь усилия разработчиков-профессионалов, помноженные на реализацию ими требований государственных стандартов (технических регламентов. Первая партия технических регламентов должна увидеть свет во втором квартале 2005 года).

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

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

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

Примеры, по мнению автора, приводить бессмысленно. Многие неоднократно сталкивались и сталкиваются с совершенно бестолковой, размазанной, как манная каша по тарелке, писаниной. Писаниной, изданной в красочной суперобложке, на глянцевой бумаге. С глоссарием. С индексом. Сверстанной по «законам восприятия». И бесполезной в плане содержания. Usability в вульгарном, а не ГОСТовском смысле.

Тем не менее, и компании-акулы, и мелкие любители национальной рыбалки в мутной водичке отечественного бизнеса едины в своем отношении к технической документации, как минимум:

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

С отношением и назначением покончено, теперь коротко о составе технической документации.

Техническая документация: состав

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

1. техническая документация на автоматизированные системы;
2. техническая документация на изделия;
3. техническая документация на программные изделия - программная документация.

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

С другой стороны, все, что производится в современых условиях, проявляет все больше и больше признаков автоматизированных систем. Мобильный телефон, к примеру, трудно назвать изделием в классическом понимании. Вот ведро или лом - это точно изделия, и ничего больше. Тот же FineReader™ можно назвать программным изделием только на дистрибутивном носителе. После инсталляции FineReader начинает автоматически распознавать тексты - становится (в совокупности с программными и техническими средствами ПЭВМ) полноценной автоматизированной системой.

В ходе дальнейшего повествования ориентировка дается на проблемы серьезных компаний.

Техническая документация: жизненный цикл

Как бы то ни было, кто бы ни занимался разработкой технической документации, каков бы ни был ее состав, обладает техническая документация, как и всё в этом мире, собственным жизненным циклом. До слез понятно, даже без ссылок на всевозможные стандарты, что жизненный цикл технической документации включает в себя, как минимум:

• процесс разработки технической документации;
• процесс публикации технической документации как на бумажных носителях, так и в электронном виде;
• процессы учета и хранения технической документации;
• процессы модификации, отслеживания изменений технической документации - сопровождения;
• процесс обмена технической документацией между подразделениями компании;
• процесс передачи технической документации Заказчику (конечному пользователю).

Чем оборачивается разработчикам жизненный цикл технической документации - известно. Шумихой, неразберихой, безответственностью - динамическим хаосом. Печально, но факт. Правда, встречаются и исключения.

Примечание. В понимании автора греческое слово «хаос» взаимно-однозначно соответствует отечественному «бардак».

Примечание 1. Поступили замечания по терминологии - «процессы жизненного цикла». Ради бога (черт с ним). Пусть будут «процедуры жизненного цикла».

Каковы же причины воцарившегося хаоса? А в типичной реализации жизненного цикла технической документации.

Техническая документация: типичная реализация жизненного цикла

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

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

Как следствие, форматы файлов, стили оформления технической документации трудно назвать единообразными и соответствующими требованиям стандартов. У каждого индивидуума свои предпочтения (в шрифтах, отступах и т.п.).

Еще одна общая беда - электронная техническая документация не структурируется должным образом. Для разбиения электронной технической документации на разделы применяются:

• стили заголовков с многоуровневой нумерацией - особо продвинутыми пользователями (крайне редко);
• нумерованные списки – Ворд достаточно «умен» и, при попытках ручного ввода нумерации разделов, иногда пытается автоматически разбить сплошной текст на разделы и подразделы в виде нумерованных списков;
• выделение строки абзацного текста жирным и ручной ввод номера раздела – лишь бы на бумаге все выглядело «изячно», если угодно - «элегантно».

Так ведь и претензии предъявить нельзя! У того же проджект-менеджера основная задача - не владение Вордом на уровне продвинутого пользователя, а получение подписи Заказчика на Акте приемки-сдачи работ. Мотивация, пардон, отсутствует.

О хранении - электронная техническая документация хранится в структуре каталогов пользовательских компьютеров и серверов. Естественно, абы как. Российский менталитет-с. Структура пользовательских каталогов хаотична. Где что лежит - в лучшем случае вспомнит лишь хозяин. Названия файлов электронной технической документации также не отличаются единообразием и удобочитаемостью. Резервное копирование файлов электронной технической документации, как правило, не производится, что приводит к утрате документов.

Об учете - попытки поставить классический учет бумажных документов терпит фиаско. Уследить за всеми участниками процесса разработки нереально. Время заказ-нарядов на машинописные работы давным-давно прошло. Быстро не «только кошки плодятся», но и документация. И также «промискуитетно».

О сопровождении технической документации - при больших объемах своевременое внесение изменений в ряд отдельных документов, отслеживание актуальных версий, архивирование старых версий технической документации невозможны. Утрачивается согласованность (непротиворечивость) технической документации.

Об обмене технической документацией внутри компании. Затребовали - отправил документ электронной почтой или показал, в каком каталоге сетевого диска документ хранится. Позднее внес в документ изменения. Не затребовали - не передал. Сбросить на расшаренный сетевой диск поленился, решил отложить на завтра - и благополучно обо всем забыл.

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

Как избежать бардака? Лаской (по проф. Преображенскому) не удается. Грозными санкциями - тоже. Единственная надежда на автоматизацию, благо все предпосылки имеют место быть.

Техническая документация: предпосылки к автоматизации процессов жизненного цикла

Каковы же предпосылки к автоматизации процессов жизненного цикла технической документации? Вот они:

• доступность специализированных средств разработки текстовых документов, построенных на основе концепции единого источника (исходника) - single source;
• замечательные особенности советской нормативно-технической документации.

Специализированных средств разработки технической (да и любой документации) навалом. Производятся таковые как отечественными компаниями, так и буржуйскими. Средства известные, на слуху, подробно останавливаться и приводить сравнительный анализ особого смысла нет. Предпочтения автора сводятся к применению при разработке (сопровождении и т.д.) технической документации программы AuthorIT от AuthorIT Software Corporation Ltd.

Большинство специализированных программных средств разработки технической документации построены по схеме, приведенной ниже (картинка заимствована с сайта компании-производителя):

Электронная техническая документация хранится в едином централизованном хранилище – в базе данных. AuthorIT позволяет применять в качестве базы данных как MS SQL, так и отдельные файлы библиотек. А вот MySQL, увы, пока не позволяет.

Библиотеки структурно подразделяются на книги, книги на разделы и подразделы, пункты и подпункты (топики) - аж до девяти уровней вложенности. Собственно топики и являются атомарными модулями данных.

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

База данных окружена оболочкой, в общем случае, включающей в себя:

• подсистему Authoring;
• подсистему Importer;
• подсистему Publisher;
• подсистему Project Manager;
• подсистему Administration.

Подсистема Authoring является средством создания, редактирования, отображения и сохранения текстов электронной технической документации - мощным текстовым процессором. При сохранении текстов электронной технической документации подсистема автоматически формирует модули данных (согласно созданной пользователем структуры разделов документа) и сохраняет указанные модули в базе данных или в файле библиотеки.

Подсистема Importer обеспечивает возможность импорта документов из файлов различных форматов (включая *.doc и *.htm) с сохранением структуры и содержания разделов документа во внутреннем формате AuthorIT.

Есть нюансы: попытка импорта неправильно структурированного вордовского документа не пройдет. Особенно, если такой файл содержит кучу OLE-объектов.

Подсистема Publisher обеспечивает возможность сборки документов из модулей данных внутреннего формата AuthorIT, публикации технической документации в различных форматах help-файлов, а также в формате MSWord. Вордовые файлы получаются замечательными - никаких проблем с кириллицей и т.п. Важно только настроить шаблон - это просто.

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

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

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

Имеется возможность сравнения различных версий, скажем, версий одного и того же раздела, с указанием - кто, что и когда добавил, изменил или удалил. Версии разделов легко «поменять местами».

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

НТД, применяемая при создании систем, изделий и программных изделий

Не далее, как 18 января 2005 года, на стол автора свалилась Программа разработки технических регламентов, утвержденная распоряжением Правительства РФ от 06 ноября 2004 г. за № 1421-р. Что будут представлять собой технические регламенты - младенцу понятно. В лучшем случае, старые советские ГОСТ единой тематики будут собраны в одну кучу и опубликованы единым документом с названием «регламент». В худшем - регламенты будут «цельнотянутыми» с буржуйских, «цельнотянутых» во время оно с советских ГОСТ. О прелестях двойного перевода говорить, уверен, даже не стоит.

Состав НТД

В настоящее время основополагающим документом при создании автоматизированных систем, изделий и программных изделий является Техническое задание (на создание АС - ГОСТ 34.602-89.) Техническое задание останется основополагающим документом и в обозримом будущем. Неважно, как будет называться этот документ - все равно это будет Техническое задание.

В ряде подразделов Технического задания приводится перечень нормативно-технической документации (НТД), на основании которой создается система.

Любая НТД, приведенная в указанном разделе согласованного и утвержденного Технического задания, обретает силу Закона как для Заказчика, так и для Исполнителя.

В целом для создания любого вида АС перечень НТД должен включать в себя:

• ГОСТ 34.601-90, регламентирующий стадии (и этапы) создания АС - описание процессов в их хронологическом порядке;
• ГОСТ 34.201-89, регламетирующий виды, комплектность и обозначения (наименования) документов, разрабатываемых на стадиях и этапах проведения работ по созданию АС;
• РД 50-34.689-90, регламентирующий требования к содержанию документов на АС;
• ряд ГОСТ 2 (ЕСКД), регламентирующих требования к содержанию и оформлению документов на изделия, входящие в состав АС;
• ГОСТ 2.601-95, регламентирующий требования к эксплуатационной документации на изделия, входящие в состав АС;
• ряд ГОСТ 19 (ЕСПД), регламентирующих требования к содержанию и оформлению документов на программные средства, входящие в состав АС;
• ряд ГОСТов по качеству технической документации;
• плюс ГОСТы (технические регламенты) предметной области.

Это был состав, теперь об особенностях.

Особенности НТД для разработки АС

Нормативно-техническая документация, перечисленная выше, обладает рядом очевидных и полезных особенностей, на которые давно обратили внимание разработчики-профессионалы:

• повторяемостью структуры разделов и содержания большинства документов;
• типовым наполнением разделов большинства документов.

Нынешним разработчикам остается только поблагодарить специалистов, принимавших участие в создании советских стандартов на автоматизированные системы, изделия и программные изделия. Как в фильме «Максим Перепелица», устами «диду Мусию» (роль сыграл совсем молодой Г. Вицин) - «Спасибо тебе, Кондрат, за такого сына!».

Следует отметить, что разработка стандартов в советские времена считалась «высшим пилотажем». К разработке привлекались специалисты наивысшей квалификации, коих сейчас, к сожалению, осталось немного. Коллективы разработчиков, как правило, становились лауреатами Государственных премий.

Повторяемость структуры и содержания ТД на АС

Техническая документация, разрабатываемая на всех стадиях и этапах создания АС согласно НТД, перечисленной выше, также характеризуется повторяемостью структуры и содержания разрабатываемых документов. Обратите внимание:

Как гласит мудрая латинская поговорка - умному достаточно. Повторяющиеся элементы структуры имеют незначительные различия:

• в ТЗ применяются штампы (клише) «требования к…»;
• в ПЗ применяются штампы «решения по…»;
• в ООП применяются штампы «описание…» и «сведения о…».

В итоге повторяющиеся по-существу разделы различных документов выглядят так:

Типовое наполнение разделов технической документации

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

Пример:

К эксплуатации системы допускается персонал:

• аттестованный на группу по электробезопасности не ниже III;
• прошедший курсы обучения ... на предприятии-изготовителе;
• и так далее...

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

Более сложный пример:

В Техническом задании - система должна обеспечивать выполнение перечисленных ниже функций:

• функции такой-то;
• функции сякой-то;
• и так далее...

В Руководстве пользователя - система обеспечивает выполнение перечисленных ниже функций:

• функции такой-то;
• функции сякой-то;
• и так далее...

Разница выделена жирным шрифтом.

Вот и все о предпосылках. Теперь о практической реализации такого подхода к разработке технической документации с применением программы AuthorIT.

Практическая реализация жизненного цикла технической документации

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

Дла начала следует скачать триальную версию AuthorIT с сайта производителя (потребуется ни к чему не обязывающая регистрация), установить оную на пользовательском компьютере, запустить и создать новую библиотеку на основе sample.adl, обозвать ее как-нибудь и закрыть (вместе с программой). По умолчанию имя пользователя - supervisor, пароля никакого, полномочия пользователя - административные.

У автора имеется разработанная им же библиотека, содержащая пока только документацию на автоматизированные системы по ГОСТ 34.602-89 и РД 50-34.698-90. Считаем, что в распоряжении читателя подобная библиотека документов также имеется.

Далее решаются проблемы множественности участников процесса разработки технической документации.

Разграничение прав и полномочий пользователей

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

1. запуском модуля AuthorIT Administrator;
2. открытием файла библиотеки (вход с именем пользователя supervisor);
3. созданием пользователей (групп пользователей);
4. назначением им паролей;
5. перекрытием кислорода.

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

Группа проджект-менеджеров должна иметь возможность внесения изменений только в Техническое задание. Значит, этой группе следует прикрыть возможность непосредственного внесения изменений в Пояснительную записку и руководство пользователя.

Группе проектантов вовсе нечего делать в Техническом задании - их задачи не выходят за рамки внесения изменений в Пояснительную записку к техническому проекту. И так далее.

Всем группам пользователей следует запретить возможность публикации документов и изменения шаблонов документов - вся техническая документация компании должна публиковаться одним ответственным лицом - supervisor'ом. Эдакая узкая горловина. Как ранее, когда без подписи нормоконтролера ни один документ не смел покинуть пределы родной фабрики. Заодно решается и проблема стилевого оформления документов.

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

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

Допустим, проектант, привыкший к ворду, налепил в топике Пояснительной записки, содержащейся в библиотеке типовых документов, сплошной неструктурированный текст. Что делать с товарищем? Возможные варианты:

1. хорошенько попинать, дабы выработать у него необходимые рефлексы и культуру изложения материала;
2. подправить все самостоятельно.

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

Проблема учета и хранения технической документации также оказывается решенной. При работе в многопользовательском режиме с базой MS SQL пользователь, не обладая специальными навыками, стащить такую базу на свой компьютер не сможет. Копировать файлы библиотек также бессмысленно, поскольку публикация документов проходит через узкую горловину supervisor'а и без его подписи ни один бумажный документ не имеет юридической силы.

Для разработки очередного типового проекта создается очередная копия файла библиотеки документов. Совокупность таких файлов автоматически формирует реестр проектов.

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

Проблема обмена технической документации между подразделениями компании оказывается исключенной. Есть база MS SQL или библиотека документов - какой смысл создавать копии и передавать их друг другу, если они изначально являются общедоступным ресурсом?

Вот приблизительная схема взаимодействия персонала подразделений компании с общим ресурсом (при использовании триальной версии AuthorIT):

ОУП - отдел управления проектами, команда проджект-менеджеров.

ПСД - проектно-сметная документация.

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

Техническая документация передается Заказчику «выпускающим» в лице supervisor'а, с неотъемлемым набором утверждающих подписей и печатей. Или на оптическом носителе в формате pdf (что не имеет особого смысла. FineReader 7 «колет» pdf-файлы, как белочка орешки. И, при этом, имеет наглость сохранять распознанное в ворде с сохранением формата оригинала).

Разработка библиотеки типовых документов

Теперь, когда показано, что большинство проблем при реализации жизненного цикла технической документации можно решить средствами автоматизации, можно перейти к десерту - показать, в чем же фишка?

А фишка проста, как все гениальное (соответствующий смайлик). Возможно, читатель обратил внимание на то, что настоящая статья содержит всего десяток-полтора заголовков разделов. На самом деле это не так. Разделов (и заголовков) в исходном документе AuthorIT'овской библиотеки примерно втрое больше, чем заголовков.

Все дело в AuthorIt'овском шаблоне с названием no heading. При применении указанного шаблона к топику (разделу документа) внутри библиотеки, текст топика при публикации, к примеру, в вордовый документ, отображается, а заголовок раздела - нет. На основе такого подхода и построена разработка библиотеки типовых документов.

Прежде всего, во вновь созданный файл библиотеки импортируются электронные версии стандартов, перечень которых приведен в подразделе Состав НТД настоящей статьи. Далее следует долгий и кропотливый процесс ручной правки - разбиения текста ГОСТов и РД на модули данных (топики), сопровождающийся созданием структуры книг - будущих отдельных документов в составе библиотеки.

Затем наступает очередь связки схожих разделов различных документов. Исходным документом, само собой, является Техническое задание. Осточертевший всем пример:

В топике раздела документа Техническое задание «Требования к численности ... персонала» записывается фраза - «Численность персонала, обслуживающего систему, должна обеспечивать:». К указанному разделу создается подраздел «ТЗ - перечень требований к численности персонала» на основе шаблона no heading. При публикации документа заголовок указанного подраздела отображаться не будет.

В подразделе записывается перечисление:

• достаточное количество персонала для выполнения обязанностей по обслуживанию системы;
• полную занятость персонала при выполнении обязанностей по обслуживанию системы.

Требования, кстати, совершенно нетестируемые. Находятся умники, включающие такие требования в Технические задания. Обойти эту глупость можно. Для этого в Пояснительной записке к техническому проекту можно записать: «на основе опыта эксплуатации подобных систем численность персонала считать достаточной и удовлетворяющей требованиям Технического задания».

Бывает и похлеще. В техническом задании: «программные срества системы должны обладать интуитивно-понятным пользовательским интерфейсом». Путь обхода - «пользователи системы должны обладать понятливостью и интуицией».

В топике раздела документа Пояснительная записка «Решение по численности ... персонала» записывается фраза «Согласно требованиям технического задания численность персонала, обслуживающего систему, обеспечивает:». К указанному разделу также создается подраздел на основе шаблона no heading «из ТЗ - перечень требований к численности персонала». И, наконец, прямо в текст подраздела перетаскивается топик «ТЗ - перечень требований к численности персонала» из технического задания. Текст вставленного топика автоматически выделяется серым цветом.

Все. Связка установлена. Теперь любые изменения указанного топика Технического задания будут автоматически сопровождаться изменением содержимого соответствующего топика Пояснительной записки и топиков других, связанных подобным образом с Техническим заданием документов. 100% согласованность достигнута.

Квалификация supervisor'а

Скоро сказка сказывается, да не скоро дело делается. Казалось бы - а что такого? Перетаскивай топики из Технического задания в схожие топики Пояснительной записки, Руководств и прочих документов. Опутывай библиотеку типовых документов сетью взаимных ссылок - и все, вопрос решен. Сажаем девочку и все будет работать само-собой.

Уважаемый читатель, снимите розовые очки (извините, хрен вы угадали!). Автор потратил на реализацию библиотеки типовых документов около полутора месяцев. Указанного времени хватило лишь на то, чтобы устроить «показуху» и убедить руководство компании, что автоматизация жизненного цикла технической документации - не из области научной фантастики и не дело далекого будущего. Без каких-либо ощутимых последствий.

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

• многолетний опыт разработки технической документации согласно требованиям ГОСТ;
• многолетний опыт взаимодействия с Заказчиком на всех стадиях и этапах проведения работ по созданию автоматизированных систем, изделий, программных изделий;
• многолетняя практика взаимодействия с «немотивированными» сотрудниками смежных подразделений компании;
• умение создать из страницы бестолкового текста короткий абзац с тремя-четырьмя четкими формулировками;
• грамотное применение штампов (клише) в техническом русском языке;
• и, наконец, знание компьютерной техники на уровне, приближающемся к уровню системного администратора.

Знания предметной области желательны, но необязательны.

Заключение

Что ж, цели достигнуты, задачи решены.

К сожалению, весь контент сайта, как и настоящую статью, автор вынужден разрабатывать и сопровождать в счет времени сна и отдыха. Кое-кто, наверное, сейчас прослезится. Но не в этом дело. Глаз автора уже «замылен», вещи, изложенные в статье, для автора очевидны. Возможно, остались вопросы без ответов. Задать вопросы можно в форуме - Форум разработчиков технической документации.

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

Да, кстати! Структура разделов настоящей статьи очень близка к ГОСТ 7.32.

Информация об авторских правах - все товарные знаки и торговые марки, упомянутые в материалах сайта, принадлежат законным владельцам. Все материалы, опубликованные на сайте без указания авторства в явном виде, принадлежат исключительно владельцам домена authorit.ru. Все материалы, опубликованные на сайте с явным указанием авторства, принадлежат исключительно авторам, предоставившим указанные материалы. Убедительная просьба ко всем, кто в коммерческих или иных целях намерен использовать материалы сайта - поимейте совесть и ссылайтесь на первоисточник в своих Интернет-ресурсах.

Версия для печати