Оформление документов

Забыл поблагодарить SergeyL за подробный анализ. Он пришелся как нельзя кстати.
ГОСТ 2.601-2006 и ГОСТ 2.610-2006 однозначно нацеливают на разработку интерактивных РЭ.
Заказчик однозначно дает понять, что если мы хотим ему что то предложить, то должны разрабатывать эксплуатационную и ремонтную документацию в интерактивном виде.
По образу и подобию вот этого

http://katalit.ru/index.php?ID=6

Вопрос несколько не в попад однако
Я думаю по Вордовски абзацный отступ 1,27 см (по умолчанию) вполне достаточно. А 2.105 изначально писался под печатные машинки. Читайте последние изменения к нему за 2006 год. думаю найдете в них кое что интересное применително к возможностям того же Ворда и т.п. прдуктов.

Разве согласно ГОСТ 2.105 абзацный отступ не должен быть 15 - 17 мм

ИЭТРы пришли к нам из МинОбороны США. И изначально определялись как

ИЭТРы делятся на классы:

Класс 1 - Бумажно-ориентированные электронные документы. Отсканированные страницы бумажных руководств. Электронный документ - копия бумажного руководства. Преимущества: большие объемы бумажной документации заменяет компактный электронный носитель. Недостатки: не добавляет никаких новых функций по сравнению с бумажными руководствами.

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

Класс 3 - Структурированные документы. Начиная с класса 3, руководства представляют собой документы, имеющие три компонента: структура, оформление и содержание. Кроме того, начиная с класса 3, ИЭТР имеют стандартизированный интерфейс пользователя. Преимущества: существует возможность стандартизировать структуру, оформление и пользовательский интерфейс руководств (например, в соответствии с отраслевыми стандартами на эксплуатационную документацию), стандартизированный интерфейс пользователя позволяет облегчить работу с ИЭТР. Недостатки: при создании руководств к сложным промышленным изделиям появляются проблемы управления большим объемом информации.

Класс 4 - Интерактивные базы данных. Руководства данного класса используют для хранения информации СУБД. Преимущества: можно создавать технические руководства большого объема. Недостатки: отсутствие системы диагностики изделия.

Класс 5 - Интегрированные базы данных. Дают возможность прямого взаимодействия с электронными модулями диагностики изделий, что существенно облегчает обслуживание и ремонт изделия. Преимущества: возможность проведения диагностики изделия. Недостатки: очень высокая стоимость создания. Вариант использования конкретного класса ИЭТР, в общем случае, зависит от сложности изделия, от финансовых и технических возможностей пользователя.

Таким образом получаем, что для создания ИЭТРа 1-го класса достаточно иметь сканнер, для второго класса - Adobe Acrobat (а лучше Adobe Acrobat 3D), для 3-го класса - отечественный TGBuilder (правда он кривой и спецы говорят, что нормального ИЭТРа в нем не получится), Macromedia'ные: Director, AuthorWare, а также другие программы, в которорых можно создать мультимедийное интерактивное приложение, а про 4-ый и 5-ый классы можете даже не думать - я слышал, что даже такой монстр как "Боинг" с трудом осилил 4-ый класс за многие тысячи уёв.

Подробно о требованиях к выполнению ИЭТР можно узнать из "АВИАЦИОННЫЙ СПРАВОЧНИК. МЕЖДУНАРОДНАЯ СПЕЦИФИКАЦИЯ ТРЕБОВАНИЙ К ТЕХНИЧЕСКИМ РУКОВОДСТВАМ, ВЫПОЛНЯЕМЫМ С ИСПОЛЬЗОВАНИЕМ ОБЩЕЙ БАЗЫ ИСХОДНЫХ ДАННЫХ. ИНТЕРАКТИВНЫЕ ЭЛЕКТРОННЫЕ ТЕХНИЧЕСКИЕ РУКОВОДСТВА (AECMA 1000D) AC 1.1.1000D-2002". Издан в 2002 г. ФГУП «НИИСУ».

Все зависит от требований предъявляемых к разрабатываемым интерактивным руководствам. Для начала посмотрите здесь
http://www.hardline.ru/3/37/3594/
Обратите внимание на HyperMethod. Лет 5 назад интересная штучка была, но не хватило времени на добросовестное изучение.

Недавно начал проработку вопросов, связанных с созданием интерактивных руководств (по требованию заказчика). Тема новая.
У кого есть опыт - поделитесь. Хотелось бы узнать, с помощью каких программных средств создаются такие изделия и оценка этих программных продуктов.

Посмотрите ссылку http://authorit.ru/forum/22 .

Пардон-те, имел в виду поручика Ржевского

Э.Э... про поручиков поаккуратнее... Плиз...

Это такие нехорошие люди, вернее, люди, обманутые америкосовской пропагандой, для которых Rational Unified Process (RUP) дороже результата. Примерно, как в том древнем анекдоте:

- Поручик, Вы любите детей?
- Никак нет-с, но сам процесс...

А кто такие РУПовцы?

Уточню, методик разработки документов, основаных на требованиях стандартов! А то опять всякие РУПовцы заведутся;)

Эт точна Никакой инструментарий не заменит методик разработки документов. Ведь важно знать, что и как писать, а не только чем писать. А наш ресурс на методиках да консультациях и построен, посему обречен на успех.

Рады за Вас ! Если что, обращайтесь еще, нам ведь тоже приятно, что наше дело живет, а главное ПОБЕЖДАЕТ !

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

Версия 1.1 этой спецификации издавалась у нас как Авиационный справочник AC 1.1.1000D-2002.
Все нововведения в ЕСКД образца 2006 года цельнотянуты из этой спецификации.

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

Тоже присоединяюсь к благодарностям за русскую текстовку.
А, если не секрет, кто это переводил и в каких целях? Эта спецификация уже где-то у нас использовалась?

Спасибо, закачал, все раскрывается.

Готово.
спецификация S1000D 2.0:
http://www.webfile.ru/1120866 - часть 1
http://www.webfile.ru/1120882 - часть 2

о HyperRUS

вот что нашел
http://www.tedopres.nl/HYPERVISION.17.0.html

Можно через http://www.webfile.ru/

Документик есть:)
На великом и могучем весит 41М, на супостатском - 55М. Кстати, отличия есть - к переводчикам масса претензий.
Ссылку могу дать только на буржуинский - http://www.s1000d.org
Родной вариант могу выслать по частям - надо договариваться ...

Сергей, а всего документика нет? :roll: Или хотя бы ссылку. (ест-но на великом и могучем).

Намедни, был на одной выставке и увидел рекламный плакатик о HyperRUS (представленный, кстати, одной фирмой из Таганрога). К сожалению, ничего не смогли рассказать об этом продукте, не было даже демо версии. Поиски в инете практически ничего не дали.

Не думаю, что Surgeon прав. По ряду причин, часть которых перечислена во вполне внятном документе
"Оформление документов в текстовом процессоре Microsoft Word"
(http://www.philosoft.ru/ru/white-papers/wordtips/wordtips.html)
на Философте.
Единственное, в чем я не готов согласиться с этим документом - это преимущества связанных рисунков перед вставленными.
Пока работаешь на одной машине - они ведут себя практически идентично. Но при передаче на другую (или при использовании локальной сети) - начинаются разнообразные глюки. То же - и при формировании из этого документа pdf-файла. Если рисунки вставлены - глюков нет.

По поводу "пп. 6.2.1-6.2.2" - там так много, что требуется время для анализа. Непременно посмотрю.

Разумно выбросить все стили, за исключением Заголовок 1 - 9 и Обычный. Меньше стилей - меньше грязи в документе.

Тоже очень толковый совет!

Как информация к размышлению - пп. 6.2.1-6.2.2 спецификации S1000D.

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

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

Если заказчику что-то не понравится, выслушайте его замечания и выполните соответствующие настройки стилей, полей в документе и пр.
Много времени это не займет

Не, его австалийские аборигены сочинили Наброски поддерживаю.

Посмотрел я этот стандарт, не наш он по дУху и даже стилю, хоть и рассчитан на компутеры (мериканьский он :twisted: ), посему разделяю мнение начальства .
Для почина могу выложить свои наброски к проектам СТО по оформлению ТД, если Surgeon поддержит .

Присоединяюсь!
В качестве зачина можно попросить г. Модератора выдернуть страничку из упомянутого ГОСТ Р-ИСО/МЭК 15910-2002 и пообсуждать-поотталкиваться.
Он-то как раз на компутеры рассчитан.

Я вообще этот стандарт люблю (ну, не сказать - "страстно", но сильно): в нем (правда, в приложении, косвенно) указаны нормы выработки для документатора - 22 страницы в месяц (разработка) и 44 страницы в месяц (редактирование).
Вот начальство моё, почему-то, его не любит

Мы пользуем (для заказчиков, демонстрирующих свою приверженность ГОСТам) вариант "поплотнее"

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

Не стоит, скачать можно здесь - http://authorit.ru/node/85

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

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

Мы пользуем (для заказчиков, демонстрирующих свою приверженность ГОСТам) вариант "поплотнее":
абзацный отступ - 10 мм, межстрочный - полуторный, интервалы перед и после - 0, шрифт - 12.
О том, что пустые строки - это плохо, уже сказано, поэтому для заголовков интервал перед: 12-18, после: 6-12, и непременно - "не отрывать от следующего". То же самое - для рисунков (чтобы не отрывались от подрисуночных подписей).
Кроме того, важны параметры страницы: верхнее поле - 25, левое - 20, нижнее - 15, правое - 10 мм (ГОСТ 19.106-78 ).
Правда, в ГОСТ Р-ИСО/МЭК 15910-2002, насколько помню, сказано, что в строке должно быть до 65 знаков. Это означает гораздо бОльшие поля. В "корпоративном стандарте" я так и сделал - мне нравится большое левое поле.

Вообще-то, в ГОСТ Р-ИСО/МЭК 15910-2002 (процесс создания документации пользователя программного средства) указаны рекомендуемые значения для всех элементов текста.
Если он кому-нибудь нужен, могу прислать.

Очень правильный совет 2 Delen .

Правила оформления текстовых документов определены ГОСТ 2.105-95. Как можно заметить из текста этого ГОСТа, правила относятся для случая оформления документа машинописным способом, который лет десять как не применяется. Новой редакции ГОСТ 2.105 нет, поскольку принятый нашими «слугами» несколько лет назад Закон о техническом регулировании не делает обязательным соблюдение требований ГОСТов. Тем не менее, все же начали появляться новые редакции отдельных стандартов ЕСКД. Этой пока нет.

Есть еще ГОСТ 2.004-88. Общие требования к выполнению конструкторских и технологических документов на печатающих и графических устройствах вывода ЭВМ, к коим можно отнести принтер, на который мы выводим документ, созданный компьютерным способом.

Есть ГОСТ 19.106-78. Требования к программным документам, выполненным печатным способом.

То, что написано в трех упомянутых стандартах, не вполне сочетается друг с другом, поэтому на практике используются следующие правила, которые не противоречат хотя бы одному из этих ГОСТов.

Абзацный отступ — 1,25 мм, межстрочный интервал — полуторный, интервалы перед - 0, после - 12 пт, между заголовком и текстом — пустая строка (или интервал после - 24 пт, если пустые строки запрещены). Между разделами — две пустые строки (или 48 пт). В содержании абзацные отступы одинаковы для всех иерархий. Текст всего документа набирается единым шрифтом Times New Roman 14 пт обычный. Заголовки разделов (только разделов, не подразделов!) набираются строчными буквами, могут быть оформлены полужирным шрифтом и могут располагаться по центру. Для кодов команд допускается использование других шрифтов, например Courier New 12 пт.

Так пока и живем, почти «по понятиям», надеясь, что примут новый ГОСТ, который все, что надо для компьютерного оформления документов, определит .

4. В ГОСТ 2.105-95, насколько помню, ограничений нет, но в требованиях по оформлению в серьезных конторах фигурируют шрифты винды по умолчанию - ариал и таймс.

1.Абзацный отступ 1,25см.
2.Для заголовка выбирайте абзацный интервал. Меню Формат->Абзац там в строках для интервала "перед" и "после" установаите по 12пт. А на закладке "Положение на странице" поставьте галочку в строке "не отрывать от следующего" (чтобы не получилось так, что заголовок последней строкой на странице, а текст к нему на следующей; так не должно быть).
3. Допустимо.