Есть ли четкие стандарты на построение файлов
ГОСТ Р 34.701.1-92
(ИСО 8632/1-87)
ГОСУДАРСТВЕННЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ
МАШИННАЯ ГРАФИКА
МЕТАФАЙЛ ДЛЯ ХРАНЕНИЯ И ПЕРЕДАЧИ
ИНФОРМАЦИИ ОБ ОПИСАНИИ ИЗОБРАЖЕНИЯ
Information technology.
Computer graphics.
Metafile for the storage and transfer of picture
description information
Дата введения 1993-01-01
1. ПОДГОТОВЛЕН И ВНЕСЕН Секретариатом ТК 22 "Информационная технология"
2. УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Постановлением Государственного Комитета Российской Федерации по стандартизации, метрологии и сертификации от 12.08.98 N 949
Настоящий стандарт подготовлен методом прямого применения международного стандарта ИСО 8632/1-87 "Системы обработки информации. Машинная графика. Метафайл для хранения и передачи информации об описании изображения" и полностью ему соответствует
3. Срок проверки 1998 г., периодичность проверки - 5 лет
4. ВВЕДЕН ВПЕРВЫЕ
5. ССЫЛОЧНЫЕ НОРМАТИВНО-ТЕХНИЧЕСКИЕ ДОКУМЕНТЫ
Обозначение отечественного НТД, на который дана ссылка
Обозначение соответствующего международного стандарта
Номер пункта, приложения
0.8, 4.7.6, 5.23, 5.3.14, 5.3.15, 5.7.20
* До прямого применения данного документа в качестве государственного стандарта, распространение его осуществляет секретариат ТК 22 "Информационная технология".
Настоящий стандарт распространяется на графические системы, использующие файлы описания графической информации, и устанавливает:
правила описания функций, при помощи которых базовые графические системы обмениваются графической информацией;
совокупность элементов, необходимую для описания графической информации;
синтаксис символьного кодирования с обеспечением минимизации размера метафайла;
синтаксис чисто текстового кодирования для чтения, редактирования и печати;
синтаксис двоичного кодирования для осуществления оптимизации скорости генерации и интерпретации метафайла.
Настоящий стандарт не распространяется на:
функции описания динамических действий базовых графических систем;
функции описания и взаимодействия трехмерных объектов;
способы генерации и интерпретации метафайла.
Для обеспечения международных правил при хранении и передачи графической информации требования стандарта по описанию функций метафайла должны соответствовать международному стандарту ИСО 8632/1-87.
В приложении к стандарту приведен перевод ИСО 8632/1-87.
ПРИЛОЖЕНИЕ
Справочное
МЕЖДУНАРОДНЫЙ СТАНДАРТ ИСО 8632/1
МАШИННАЯ ГРАФИКА
МЕТАФАЙЛ ДЛЯ ПЕРЕДАЧИ И ХРАНЕНИЯ
ИНФОРМАЦИИ ОБ ОПИСАНИИ ИЗОБРАЖЕНИЯ
Часть 1. ФУНКЦИОНАЛЬНОЕ ОПИСАНИЕ
0. ВВЕДЕНИЕ
Метафайл Машинной Графики (ММГ) определяет формат файла для хранения и редактирования графической информации. Формат файла состоит из ряда элементов, которые могут быть использованы для описания изображений методом, совместимым с системами различных архитектур и устройствами различных возможностей и назначения.
0.2. Обоснование для данного международного стандарта
Основные цели стандартизации Метафайла Машинной Графики заключаются в необходимости:
а) представления возможности накопления графической информации организованным способом в системе графического программного обеспечения;
б) организации передачи графической информации между различными системами графического программного обеспечения;
в) обеспечения передачи графической информации между графическими устройствами;
г) обеспечения передачи графической информации между различными графическими системами.
0.3. Требования к построению стандарта
Для достижения перечисленных целей был принят ряд требований к построению:
а) Метафайл должен предусматривать соответствующий набор элементов для передачи широкого диапазона графической информации.
б) Метафайл должен непосредственно работать с более распространенными и важными средствами графических устройств и должен обеспечивать доступ к менее общим средствам через механизм расширения.
в) Создание метафайла не должно исключать возможность расширения ИСО 8632 на более поздней стадии для развития средств, не включенных в настоящий стандарт.
г) Метафайл должен предоставлять возможность использования ЯГС (ЯГС - Ядро Графической Системы - ИСО 7942) как с функциями ввода, так и с функциями вывода метафайла.
д) Стандарт ИСО 8632 должен допускать возможность решения различных прикладных задач, что подразумевает изменяющиеся требования к размеру метафайла, скорости генерации и интерпретации, читабельности, редактированию и простоте передачи через различные устройства передачи.
0.4. Принципы построения стандарта
Требования, перечисленные в п.0.3, учитывались при определении принципов, которые использовались для выбора альтернатив в процессе построения.
В любой области стандарта ИСО 8632 функциональность, установленная стандартом ИСО 8632, сама по себе полна.
Следует избегать избыточных элементов или параметров.
Следует избегать противоречащих друг другу элементов.
Следует предусмотреть возможность добавления новых элементов и применимость их ко всему стандарту.
Минимальные результаты и характеристики элементов должны быть четко определены.
Необходимо, чтобы большинство головных систем и/или аппаратных средств графики эффективно поддерживали любой элемент.
Элементы должны быть независимы друг от друга или любая зависимость должна быть структурирована и четко определена.
ИСО 8632 должен быть таким, чтобы рекомендуемое и правильное использование стандартных элементов гарантировало бы результаты использования каждого отдельного элемента.
и) Использование стандарта
Должны быть стандартизованы только те элементы, которые отражают практическое применение, необходимые для реализации существующего применения или для поддержки предлагаемых стандартов.
Функции должны быть достаточно эффективными для выполнения необходимых задач.
Предположения о том, как элементы располагаются друг относительно друга, должны быть минимизированы. Элемент должен иметь четко определенный интерфейс и просто сформулированную безусловную цель. Должны быть исключены многоцелевые элементы и сторонние эффекты пересечения элементов.
0.5. Доступ к метафайлу
Метафайл построен так, что хотя его основное использование предполагается с полностью последовательным доступом, также возможен прямой доступ. После того, как основная среда метафайла установлена, отдельные изображения становятся доступны, если среда, кодирование и реализация поддерживают эту форму доступа.
0.6. Генерация и интерпретация метафайлов
Конкретный механизм генерации и интерпретации метафайла не описан в стандарте ИСО 8632, хотя он и описывает предполагаемый результат такой интерпретации. Основной набор элементов метафайла предусматривает возможность добавления данных прикладных программ, которые не имеют графического смысла и для которых не описывается никаких предназначенных результатов интерпретации.
0.7. Различие между формальной спецификацией и кодированием
Функциональные возможности, предусматриваемые метафайлом, отделяются от спецификации любого конкретного формата кодирования. Стандарт ИСО 8632 предусматривает следующие способы кодирования элементов: стандартный и для личного пользования.
Правила согласования кодирования для личного пользования установлены в приложении Б. Это приложение является необязательной частью стандарта ИСО 8632.
Три стандартных метода кодирования установлены в частях 2, 3 и 4 ИСО 8632. Каждый стандартный метод кодирования вмещает все функциональные возможности, описанные в этой части ИСО 8632. Переход между стандартными методами кодирования возможен без потери информации об изображении, хотя последующий переход в начальное кодирование может не привести в точности к тому же потоку данных из-за различной дискредитации точности в различных методах кодирования.
Символическое кодирование, определенное в ИСО 8632, предусматривает кодирование в минимальном объеме. Оно согласуется с правилами расширенного кодирования, определенного в ИСО 2022, в категории полной системы кодов. Особенно подходящим оно является для передачи по сетям, которые не могут обеспечивать двоичной передачи.
Двоичное кодирование, определенное в ИСО 8632-3, предусматривает кодирование, которое требует наименьших усилий при генерации и интерпретации на многих системах.
Чисто текстовое кодирование, определенное в ИСО 8632/4, предусматривает кодирование, результаты которого могут быть сформированы, просмотрены и отредактированы стандартным редактором текста. Поэтому оно также доступно передаче через сеть, способную передавать только текстовые файлы.
0.8. Связь с другими международными стандартами
Стандарт ИСО 8632 наиболее полно отражает модель графической системы ЯГС (Ядро Графической Системы - ИСО 7942). Дополнительно стандарт ИСО 8632 определяет метафайл, который может быть использован как статический метафайл ЯГС. Один вариант связи между этим стандартом и ЯГС описан в приложении Г (используется подмножество элементов этого стандарта как статистический метафайл обработки изображения посредством ЯГС).
Кратко об авторе исходной статьи: Адам Босворт (Adam Bosworth) начал карьеру в Borland, где работал над системой электронных таблиц Quattro. Перейдя в Microsoft он занимал различные руководящие должности, включая пост главного руководителя группы WebData, занятой созданием и продвижением XML. Кроме этого он занимался Access и движком Internet Explorer 4.0 с кодовым именем Trident. Уйдя из Microsoft Адам вошел в число сооснователей Crossgain, после ряда поглощений их основной продукт превратился в Oracle Workshop for WebLogic. В 2004-2007 годах Босворт занимал пост вице-президента по разработке продуктов в Google, где занимался Google Docs и руководил разработкой Google Health (закрыта с 1 января 2012, когда-то о ней писали на хабре). После ухода из Google он основал стартап Keas, использующий элементы социальных сетей и игр для улучшения здоровья.
На этой неделе меня любезно попросили принять участие в качестве эксперта в правительственном совещании (1) о стандартах. В это время я обычно сплю, но в нужный момент я был бодр и сидел у телефона, несмотря на все свое отвращение к недосыпанию. Что заставило меня так поступить? Обсуждались способы, с помощью которых медицинские данные можно было бы на самом деле сделать прозрачными. Какие стандарты надо использовать для совмещения подобных данных?
К собственному удивлению и в какой-то степени боли, я успел поучаствовать в разработке нескольких стандартов. Один из них использовался для обмена данными между базами данных и пользовательскими приложениями вроде электронных таблиц или Access. Он назывался ODBC и отлично показал себя, несмотря на некоторые затруднения в начале. Другим был стандарт того, что сейчас называется AJAX, создания сложных, интерактивных веб-страниц вроде Gmail. Наверное самым важным был XML. Это все успехи. Были и провалы. Особенно хорошо я помню OLE DB, которым мы хотели заменить/вытеснить ODBC. Одним из балансировавших на грани успеха и провала был/является XML Schema. В результате всех этих усилий я выучил несколько уроков, которыми постараюсь поделиться с вами. Каковы они?
1. Делайте стандарты предельно простыми и глупыми. Вероятность провала — это как минимум квадрат сложности стандарта. Успешные стандарты как правило просты, сосредоточены и легко читаемы. В мире медицины это означает, что надо прежде всего сосредоточиться на тех данных, которые могут быть однозначно закодированы: демографических параметрах, результатах анализов, лекарствах. Не надо стараться охватить все виды медицинских данных из всех областей медицины. Не надо сосредотачиваться на правах доступа ваших партнеров к различным данным (смотрите пункты 2, 3 и 4 далее).
4. Стандарты должны включать в себя точные правила кодировки. ODBC точно определял типы данных. В описании XML все было кратким, за исключением точных правил кодирования символов в тексте, юникода. Это, наверное, самая важная часть стандарта, так как она гарантирует точность кодировки. В здравоохранении это означает, что стандарт должен четко определять правила кодировки лекарств, результатов анализов, демографических данных, данных о состоянии больного и гарантировать, что все смогут использовать эти правила без выплаты лицензионных отчислений. Правительство может повлиять на это, требуя NPI для всех данных о действиях врачей, SNOMED CT для всех данных о состоянии больного, LOINC для всех лабораторных данных, определенных правил кодировки для всех лекарств (которыми могут быть NDC, rxNorm или FDB) и гарантируя, что использование этих правил всегда будет бесплатным.
5. Всегда должны быть существующие на практике реализации, которые на самом деле учитываются при конструировании стандарта. Не сделав что-то очень сложно понять, будет ли оно работать и иметь инженерный смысл. При создании ODBC многие из нас реализовывали его в процессе работы. В мире здравоохранения многие из нас развивали и использовали CCR в ходе его создания, сразу разбираясь с тем, что работает, а что не особенно полезно, благодаря чему он стал хорошим, простым в использование стандартом по интеграции медицинских данных. Рядовой инженер должен быть в состоянии разобраться в реализации стандарта за несколько недель.
7. Сделайте сам стандарт бесплатным и опубликуйте его в интернете вместе с множеством простых примеров. Инженеры тоже люди, им проще всего учиться на примерах и если стандарт следует вышеописанным принципам, примеры будут ясными и очевидными. Обычно можно сразу предсказать успех стандарта, если на его сайте есть четкое описание и простые, понятные всем примеры. Сложность, обобщенность и абстрактность HL7 полностью ошеломляет обычного человека, зашедшего на его сайт. Она приводит в замешательство даже меня. Не заблуждайтесь, инженеры — это обычные люди, у которых очень мало времени. Большинство из них не имеют ученой степени.
Честно говоря, большинство стандартов созданы вовсе не для обеспечения совместимости. Некоторые созданы для защиты уже имеющегося положения или получения прибыли с интеллектуальной собственности. Другие существуют сами по себе, поддерживая бесконечное существование тела стандарта и давая возможность авторам зарабатывать очень неплохие деньги на банальном объяснении бедным инженерам особенностей работы своего стандарта. Наверное все согласятся, что хорошими такие стандарты не назовешь. Совместимость медицинских данных слишком важна для нас всех, чтобы мы позволили ей пасть жертвой подобного подхода.
1. Ссылка на описание совещания не работает. Блога, в котором оно было опубликовано, тоже уже нет. По названию ссылки можно предположить (не зная американской специфики), что это был блог FACA — одной из специальных совещательных организаций, созданных на основе закона 1972 года и предназначенных для выработки общедоступных рекомендаций правительственным органам и президенту
Вольный перевод статьи «Should we use a coding standard?» из блога «Virtuous Code» Avdi Grimm. Мнение автора оригинальной статьи может не совпадать с мнением редакции.
Примечание переводчика: лично я согласен с автором.
Avdi, должны ли мы использовать стандарт разработки?
Какой стандарт нам использовать?
Не думаю, что есть какой-то один «правильный» стандарт. Каждый проект должен выработать свой стандарт на основе своих нужд и предпочтений разработчиков.
Думаю, что разнообразие стилей в сообществе хорошо. Это хорошо даже для большой организации.
Когда я работал в такой организации, у нас была пара рекомендованных стандартов для любого используемого нами языка. Но окончательный выбор стандарта для каждого нового проекта оставался на совести тимлида.
Я думаю, что выбор стандарта для каждого конкретного проекта — хорошая детализация. Таким образом, у каждого отдельно взятого репозитория и каждой команды может быть отдельный стандарт.
Как нам выбрать стандарт разработки?
Многие сообщества языков программирования уже выработали общие стандарты. К примеру, если вы пишете код на C, вы можете выбрать стандарт разработки GNU. Или если вы разрабатываете на Ruby, вы можете использовать стандарт сообщества, поддерживаемый Божидаром Бацовым: Bozhidar Batsov’s community-influenced standard.
Эти стандарты — плод мыслей и дебатов сообщества. Поскольку соглашения, входящие в эти стандарты, основаны на решении большинства, это хорошая точка отсчета.
Но некоторые решения в этих стандартах — глупые и неправильные!
Истина. Поэтому я и говорю, что стандарты сообщества — хорошая отправная точка. Когда у вашей команды есть четкие возражения по определенным соглашениям в стандартах — наступает время для модификации стандарта под свои нужды.
Наша команда разделилась пополам в выборе определенного пути! Как я могу убедить другую половину?
Будем честны: очень маловероятно, что команда действительно разделилась пополам. Обычно есть один-два человека с одной стороны и примерно столько же с другой, остальная же команда не выбирает ни одну сторону.
Хорошо, так как мне убедить этих людей по другую сторону баррикад?
Уверенность другой стороны могут поколебать хорошо обоснованные, реальные примеры того, что ваш вариант изящнее раскрывает суть кода, лаконичнее пишется или лучше показывает опасные места.
Это не так, просто мой стиль красивее. В любом случае, это более идиоматичный подход.
После многих лет знакомства с разными стандартами разработки я могу сказать, что сильнее всего на отношение к стандарту влияет знакомство с этим самым стандартом. Даже не помню, сколько раз я приходил в проект со стандартом, который я просто ненавидел, но после шести недель работы переставал об этом беспокоиться. Иногда я даже использовал его как новый стандарт для собственных проектов.
Например, когда я начинал разрабатывать на C++, я выравнивал фигурные скобки так, чтобы можно было посмотреть выше и сразу увидеть открывающую скобку в той же колонке:
Позже я встретился с кодом в стиле GNU/GNOME, где открывающая скобка стоит на строке с объявлением метода. Аргх!
Я пожал плечами и продолжил. Вариант в GNU-стиле даже показался мне предпочтительнее.
Мне встречалось множество примеров кода вроде «А против Б», где вариант Б представляли объективно красивее варианта А. Большую часть времени мне было сложно увидеть разницу, которую автор полагал очевидной.
В Ruby популяризованное Rails соглашение о выборе между фигурными скобками и do. end, основанное на количестве строк кода внутри блока, немного глупо. Мне говорили, что одна из причин такого соглашения в том, что do. end на одной строке объективно выглядит ужасно:
Лично я не вижу ничего плохого в этой строке. Объективные эстетические суждения плохи в качестве правил.
Так как это слова на английском, давайте рассмотрим это с точки зрения английского языка.
Точка обычно указывает конец предложения, или разделитель между целой и дробной частью числа. Здесь она стоит на том месте, где обычно мы ставим запятую:
Тем временем слова отделяются друг от друга символом, которого новички вообще не знают. Я уже даже не хочу думать о кавычках.
Окей, хорошо, стиль субъективен. Но некоторые вещи действительно делают код проще, или ошибки заметнее!
Да, думаю это так.
И мой тимлид делает неверный выбор!!
Возможно, что у вас действительно есть хорошие, целостные, ориентированные на качество кода аргументы в пользу определенного стиля. И вопрос выбора стандарта действительно может развести вас и вашу команду по разные стороны баррикад.
Есть один важный вопрос, который необходимо задавать себе, ратуя за выбор определенного стиля кода. Это настолько важно, что я напишу его отдельной строкой.
Как дорого проекту обойдется ваша правота?
Давайте посмотрим: вы полностью правы насчет выбора стиля или практики разработки. Ваши оппоненты неправы и глупы.
- Потраченные часы всей команды на совещания касательно стиля, которые не заканчиваются ничем толковым?
- Потерю хороших отношений как результат столкновений лбами на этих совещаниях?
- Цену огромных цепочек в почте с обсуждениями плюсов и минусов разных стандартов?
- Злость и гнев вашей команды, когда они будут вынуждены следовать стилю, который им не нравится, но который им в итоге навязали?
Некоторые стандарты разработки стоят всего этого. Но я рекомендую хорошо подумать, прежде чем бросаться в бой.
Стандарты разработки предохраняют от дурных привычек, но в чем их главный плюс?
Стандарты разработки дают программистам, особенно неопытным, определенную защиту от дурных привычек, но я не считаю это главным преимуществом. Для меня главный выигрыш от стандартов — это последовательность.
Сравним два блока кода на Ruby:
Очевидно ли на первый взгляд, что оба блока делают одно и то же? Более важно: очевидно ли, что несмотря на аналогичную функциональность, блоки имеют мелкое, но важное различие?
Реальная ценность стандарта разработки в том, что он делает похожие вещи похожими, а разные — разными. Такая последовательность помогает команде быстрее понимать суть написанного кода. В свою очередь это означает, что они могут работать на более высоком уровне абстракции большую часть времени.
Как это понимать для легаси-кода? Должны ли мы обновлять каждый файл в проекте под новый стандарт?
Одним словом — нет. Не вижу никакой пользы в том, чтобы потратить часы на обновление каждого файла в проекте строчка за строчкой согласно новому стандарту разработки. Это не стоит тех затрат времени и усилий, и может принести новые баги в легаси-код.
Что, если я вношу изменение в легаси-код? Должен ли я обновить весь файл, раз уж я за него взялся?
Мой ответ отличается от общепринятого мнения и порой удивляет людей.
Ответ — нет. Обновление стиля легаси-кода потребует времени, создаст большой diff и увеличит шанс случайной регрессии.
Значит ли это, что я должен использовать новый стиль только в новых или измененных участках кода?
Давайте конкретизируем вопрос. Представьте, что это кусок легаси-кода:
Предположим, ваша задача — добавить слово «they» в список. И по новому стандарту разработки все строки должны обрамляться двойными кавычками.
Нужно ли обновить весь список в процессе добавления нового слова?
Или применить новый стандарт только для добавленной строки?
Как я говорил раньше, для меня ценность стандарта — сохранение последовательности. Последовательность важна на уровне проекта, но она важна и на уровне файла. Поэтому я не думаю, что стоит следовать новому стандарту, когда вы обновляете файл, написанный по старому стандарту. Напротив, если в файле уже есть последовательный стиль оформления, вам стоит постараться выдержать его.
Это значит, что если слова в списке обрамлены одиночными кавычками, вы должны добавить новое слово в одиночных кавычках.
Если вы часто обновляете файл с легаси-кодом, тогда мне кажется хорошей идеей запланировать обновление конкретно этого файла по новым стандартам. Но не думаю, что стоит превентивно обновлять малоиспользуемые файлы. И я не поддерживаю локально несогласованные изменения только ради того, чтобы оставаться в рамках стандарта.
Что думаете о стандартах разработки? Какие стандарты применяете? Рассказывайте.
Документация – такая штука, к которой мало кто питает тёплые чувства: скучно, занудно, однообразно. И, тем не менее, иногда не возникает сомнений в её необходимости: ведь кому-то после вас этим пользоваться или, тем паче, модифицировать. И тогда появляется вопрос: как сделать документацию правильно?
Существует тьма статей на тему «как писать документацию», но если вы решили взяться за неё в первый раз, то в новой для вас области не сразу понятно, дело ли пишет автор, или отсебятину выдумывает.
Для того чтобы сформировать своё мнение без перелопачивания статей, можно пойти двумя путями: довериться некому авторитету или посмотреть в стандарты – уж там-то с наибольшей вероятностью проблему обдумали со всех сторон.
Кто-то может сказать «а-а, стандарты! они ещё более адово скучные, чем сама документация!». Ну, не будем врать, есть немного :) Но если у вас документ в электронном формате – найти необходимое не составляет труда. И кроме того, ну надо же размочить раздел стандарты уже, а то висит пустой, даже обидно.
Обратимся сначала к ГОСТ-ам. Они расстраивают датами разработки (впрочем, похоже, за эти годы в документировании не многе изменилось) и радуют бесплатностью.
ГОСТ 34.602-89 «Техническое задание на создание автоматизированной системы» — стандарт на ТЗ. Спасибо Jazzist.
Буржуйские.
Не было предела моему возмущению, когда я узнала, что международные стандарты не бесплатные. Это как правила дорожного движения сделать платными. Но в принципе, может и резонно: организации-то не государственные. Хотят – могут и деньги брать за свою работу. К счастью, многие стандарты можно скачать по-привычному, по-пиратски.
IEEE Std 1063-2001 «IEEE Standard for Software User Documentation» — в документе обозначены требования к структуре, содержимому и формату инструкций пользователя.
Официальная страница.
IEEE Std 1016-1998 «IEEE Recommended Practice for Software Design Descriptions» — рекомендации к документам, описывающим архитектуру программного обеспечения, то бишь к техническому описанию.
Официальная страница.
Особливо понравилась табличка-экстракт основного содержания документа (здесь вольный перевод):
Тип обзора | Содержание | Атрибуты | Примеры представления |
---|---|---|---|
Декомпозиция | Разбиение системы на структурные составляющие | Определение, тип, назначение, функции, зависимые сущности | Иерархическая диаграмма декомпозиции, словесное описание. |
Описание зависимостей | Описание связей между сущностями и системными ресурсами. | Определение, тип, назначение, зависимости, ресурсы. | Структурные схемы, диаграммы потоков данных, схемы транзакций. |
Описание интерфейса | Список всего, что может потребоваться знать проектировщику, программисту или тестеру для того чтобы использовать структурные составляющие системы. | Определение, функции, интерфейсы. | Файлы интерфейса, таблицы параметров. |
Описание деталей | Описание внутреннего устройства частей сущности. | Определение, обработка данных, данные. | Блок-схемы, N-S диаграммы, PDL |
ISO/IEC FDIS 18019:2004 «Guidelines for the design and preparation of user documentation for application software» — рекомендации по созданию документации пользователя. Так сказать, советы «хозяйке на заметку». Довольно приятное руководство с большим количеством примеров (имхо, больше подходит для чтения до или в самом начале создания документации, так как подходит к процессу основательно, от самого планирования). Также в приложениях есть чеклисты «что не забыть сделать в процессе разработки документации» и «что должно быть в документе»
Официальная страница.
ISO/IEC 26514:2008 «Requirements for designers and developers of user documentation» — довольно свежий и, судя по содержанию, полезный документ. Но, как раз, видимо, ввиду его свежести, этот стандарт нигде не найти бесплатно. По крайней мере, мне этого сделать не удалось.
Официальная страница.
Это были стандарты, наиболее тесно связанные с документированием. Они могут пригодиться как начинающему техпису, так и, например, фрилансеру, который «и швец, и жнец, и на дуде игрец».
Уточнения, дополнения и полезные ссылки приветствуются)
UPD: очень познавательный комментарий, спасибо lkochetova
UPD1: совесть меня таки замучила, и в статье больше не будет висеть прямых ссылок на скачивание стандартов, не распространяемых свободно. Если они вам понадобятся — нагуглить не составит труда.
UPD2: также смотрите статью Документирование по ГОСТ 34* — это просто с подробным разбором отечественных стандартов на проектную документацию.
Единая система конструкторской документации
ОБЩИЕ ТРЕБОВАНИЯ К ТЕКСТОВЫМ ДОКУМЕНТАМ
Unified system for design documentation. General requirements for textual documents
____________________________________________________________________
Текст Сравнения ГОСТ 2.105-95 с ГОСТ Р 2.105-2019 см. по ссылке.
- Примечание изготовителя базы данных.
____________________________________________________________________
МКС 01.110
ОКСТУ 0002
Дата введения 1996-07-01
1 РАЗРАБОТАН Всероссийским научно-исследовательским институтом стандартизации и сертификации в машиностроении (ВНИИНМАШ) Госстандарта России
ВНЕСЕН Госстандартом Российской Федерации
2 ПРИНЯТ Межгосударственным Советом по стандартизации, метрологии и сертификации (протокол N 7 от 26 апреля 1995 г.)
За принятие проголосовали:
Наименование национального органа по стандартизации
Госстандарт Республики Беларусь
Госстандарт Республики Казахстан
Изменение N 1 принято Межгосударственным советом по стандартизации, метрологии и сертификации по переписке (протокол N 23 от 28 февраля 2006 г.)
За принятие изменения проголосовали национальные органы по стандартизации следующих государств: AZ, AM, BY, KZ, KG, MD, RU, TJ, TM, UZ, UA [коды альфа-2 по МЭК (ИСО 3166) 004]
3 Постановлением Комитета Российской Федерации по стандартизации, метрологии и сертификации от 8 августа 1995 г. N 426 межгосударственный стандарт ГОСТ 2.105-95 введен в действие в качестве государственного стандарта Российской Федерации с 1 июля 1996 г.
4 ВЗАМЕН ГОСТ 2.105-79, ГОСТ 2.906-71
5 ИЗДАНИЕ (апрель 2011 г.) с Изменением N 1, утвержденным в июне 2006 г. (ИУС 9-2006), Поправкой (ИУС 12-2001)
ВНЕСЕНЫ: поправка, опубликованная в ИУС N 2, 2012 год; поправка, опубликованная в ИУС N 1, 2018 год
Поправки внесены изготовителем базы данных
2 Нормативные ссылки
В настоящем стандарте использованы ссылки на следующие стандарты:
ГОСТ 2.004-88 Единая система конструкторской документации. Общие требования к выполнению конструкторских и технологических документов на печатающих и графических устройствах вывода ЭВМ
ГОСТ 2.104-2006 Единая система конструкторской документации. Основные надписи
ГОСТ 2.106-96 Единая система конструкторской документации. Текстовые документы
ГОСТ 2.109-73 Единая система конструкторской документации. Основные требования к чертежам
ГОСТ 2.301-68 Единая система конструкторской документации. Форматы
ГОСТ 2.304-81 Единая система конструкторской документации. Шрифты чертежные
ГОСТ 2.316-2008 Единая система конструкторской документации. Правила нанесения надписей, технических требований и таблиц на графических документах. Общие положения
ГОСТ 2.321-84 Единая система конструкторской документации. Обозначения буквенные
ГОСТ 2.503-90 Единая система конструкторской документации. Правила внесения изменений
* На территории Российской Федерации отменен без замены.
ГОСТ 7.32-2001 Система стандартов по информации, библиотечному и издательскому делу. Отчет о научно-исследовательской работе. Структура и правила оформления
ГОСТ 8.417-2002 Государственная система обеспечения единства измерений. Единицы величин
ГОСТ 13.1.002-2003 Репрография. Микрография. Документы для микрофильмирования. Общие требования и нормы
ГОСТ 21.101-97* Система проектной документации для строительства. Основные требования к рабочей документации
* На территории Российской Федерации действует ГОСТ Р 21.1101-2009.
ГОСТ 14236-81 Пленки полимерные. Метод испытания на растяжение
(Измененная редакция, Изм. N 1).
3 Общие положения
3.1 Текстовые документы подразделяют на документы, содержащие, в основном, сплошной текст (технические условия, паспорта, расчеты, пояснительные записки, инструкции и т.п.), и документы, содержащие текст, разбитый на графы (спецификации, ведомости, таблицы и т.п.).
Текстовые документы выполняют в бумажной форме и (или) в форме электронного документа (ДЭ).
Допускается в текстовых документах, содержащих текст, разбитый на графы, использовать сокращения слов по ГОСТ 2.316.
(Измененная редакция, Изм. N 1).
3.2 Текстовые документы выполняют на формах, установленных соответствующими стандартами Единой системы конструкторской документации (ЕСКД) и Системы проектной документации для строительства (СПДС).
Требования, специфические для некоторых видов текстовых документов (например, эксплуатационных документов), приведены в соответствующих стандартах.
3.3 Подлинники текстовых документов выполняют одним из следующих способов:
- машинописным, при этом следует выполнять требования ГОСТ 13.1.002. Шрифт пишущей машинки должен быть четким, высотой не менее 2,5 мм, лента только черного цвета (полужирная);
- рукописным - чертежным шрифтом по ГОСТ 2.304 с высотой букв и цифр не менее 2,5 мм. Цифры и буквы необходимо писать четко черной тушью;
- с применением печатающих и графических устройств вывода ЭВМ (ГОСТ 2.004);
- на электронных носителях данных.
3.4 Копии текстовых документов выполняют одним из следующих способов:
- типографским - в соответствии с требованиями, предъявляемыми к изданиям, изготовляемым типографским способом;
- ксерокопированием - при этом рекомендуется размножать способом двустороннего копирования;
- на электронных носителях данных.
3.3, 3.4 (Измененная редакция, Изм. N 1).
3.5 Вписывать в текстовые документы, изготовленные машинописным способом, отдельные слова, формулы, условные знаки (рукописным способом), а также выполнять иллюстрации следует черными чернилами, пастой или тушью.
3.6 Расстояние от рамки формы до границ текста в начале и в конце строк - не менее 3 мм.
Расстояние от верхней или нижней строки текста до верхней или нижней рамки должно быть не менее 10 мм.
Абзацы в тексте начинают отступом, равным пяти ударам пишущей машинки (15-17 мм).
Пример выполнения текстового документа приведен в приложении А.
3.7 Опечатки, описки и графические неточности, обнаруженные в процессе выполнения документа, допускается исправлять подчисткой или закрашиванием белой краской и нанесением на том же месте исправленного текста (графики) машинописным способом или черными чернилами, пастой или тушью рукописным способом.
Повреждения листов текстовых документов, помарки и следы неполностью удаленного прежнего текста (графика) не допускаются.
После внесения исправлений документ должен удовлетворять требованиям микрофильмирования, установленным ГОСТ 13.1.002.
3.8 Для размещения утверждающих и согласующих подписей к текстовым документам рекомендуется составлять титульный лист и (или) лист утверждения в соответствии с разделом 6 настоящего стандарта.
Обязательность и особенности выполнения титульных листов оговорены в стандартах ЕСКД и СПДС на правила выполнения соответствующих документов.
3.9 К текстовым документам рекомендуется выпускать лист регистрации изменений в соответствии с ГОСТ 2.503 и ГОСТ 21.101.
3.10 Содержательная и реквизитная части ДЭ должны соответствовать требованиям стандарта ЕСКД.
Структура и состав реквизитов ДЭ должны обеспечивать его обращение в рамках программных средств (отображение, внесение изменений, печать, учет и хранение в базах данных, а также передачу в другие автоматизированные системы) с соблюдением при этом нормативных требований по оформлению текстовых документов.
1 Область применения
Настоящий стандарт устанавливает общие требования к выполнению текстовых документов на изделия машиностроения, приборостроения и строительства.
Читайте также: