ГОСТ 19 и 34 СЕРИИ при оформлении документации. Как пишется по стандарту


по стандарту - это... Что такое по стандарту?

  • Качество По Стандарту — качество товаров, соответствующее определенному стандарту. Словарь бизнес терминов. Академик.ру. 2001 …   Словарь бизнес-терминов

  • ассоциация “Меморандум о взаимопонимании и содействии стандарту TETRA” — Ассоциация “Меморандум о взаимопонимании и содействии стандарту TETRA”, объединяющая производителей, разработчиков программного обеспечения, испытательные лаборатории, операторов и пользователей из многих стран. [Л.М. Невдяев.… …   Справочник технического переводчика

  • предохранитель по стандарту DIN — Рис. LS Industrial Systems Предохранители по стандарту DIN Тематики предохранитель EN DIN type fuse …   Справочник технического переводчика

  • продукция, не соответствующая стандарту — сущ., кол во синонимов: 1 • нестандарт (1) Словарь синонимов ASIS. В.Н. Тришин. 2013 …   Словарь синонимов

  • не соответствующий стандарту — прил., кол во синонимов: 2 • некондиционный (34) • нестандартный (32) Словарь синонимов ASIS. В.Н. Тришин. 2013 …   Словарь синонимов

  • Военное дополнение к стандарту — е) военное дополнение к стандарту документ по стандартизации, принятый органом, уполномоченным утверждать (принимать) соответствующие стандарты, дополняющий требования стандарта (межгосударственного, государственного, отраслевого) в отношении… …   Официальная терминология

  • Дополнение к военному стандарту на период военного положения — в) дополнение к государственному (национальному) военному стандарту на период военного положения документ, устанавливающий измененные требования государственного (национального) военного стандарта, направленные на повышение производственных… …   Официальная терминология

  • Подтверждение соответствия национальному стандарту — (национальным стандартам): Документальное удостоверение соответствия продукции положениям (требованиям) национального стандарта (национальных стандартов)... Источник: ГОСТ Р 1.9 2004. Стандартизация в Российской Федерации. Знак соответствия… …   Официальная терминология

  • Соответствие национальному стандарту — (национальным стандартам): Соблюдение изготовителем (производителем) всех установленных в конкретном национальном стандарте (национальных стандартах) требований к продукции... Источник: ГОСТ Р 1.9 2004. Стандартизация в Российской Федерации. Знак …   Официальная терминология

  • Сертификат соответствия стандарту Евро-4 — Эта статья предлагается к удалению. Пояснение причин и соответствующее обсуждение вы можете найти на странице Википедия:К удалению/8 декабря 2012. Пока процесс обсуждени …   Википедия

  • соответствующий стандарту — прил., кол во синонимов: 1 • стандартный (22) Словарь синонимов ASIS. В.Н. Тришин. 2013 …   Словарь синонимов

  • russian_latvian.academic.ru

    Как правильно пишется слово СТАНДАРТ. Ударение в слове СТАНДАРТ

    станда́рт

    Делаем Карту слов лучше вместе

    Привет! Меня зовут Лампобот, я компьютерная программа, которая помогает делать Карту слов. Я отлично умею считать, но пока плохо понимаю, как устроен ваш мир. Помоги мне разобраться!

    Спасибо! Я стал чуточку лучше понимать мир эмоций.

    Вопрос: зафрахтовать — это что-то положительное, отрицательное или нейтральное?

    Положительное

    Отрицательное

    Предложения со словом «стандарт»:

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

    Оставить комментарий

    Текст комментария:

    Дополнительно:

    Слово «стандарт» входит в списки слов:

    kartaslov.ru

    Как написать стандарт (если вам очень нужно)

    Стандарты в целом являются плохой идеей. Они уменьшают свободу действий и ограничивают выбор. Но иногда вам нужно иметь один, чтобы успокоить регулятора, настроенного против бизнеса, или бюрократа социалистического толка. Итак, что нужно делать, если вы неожиданно обнаруживаете, что вам нужно срочно обратиться в Департамент по стандартам? Безусловно, создать стандарт и сделать это быстро! Я предлагаю здесь некоторые обобщения передового опыта, а также проверенные и надежные советы, как сделать стандарт быстро, с минимальными заморочками или риском.

    Сначала небольшой ликбез. Написание стандартов, как это обычно делается, представляет собой многосторонний, совещательный процесс, в котором рассматриваются и обсуждаются несколько точек зрения - до тех пор, пока консенсус не будет достигнут и задокументирован. Этого нужно избежать любой ценой. Задержки, обусловленные таким  процессом консенсуса, весьма значительны, и результаты такого процесса не оправдывают затраченного на них времени. Если у вас уже есть монополия, зачем терять время в поисках консенсуса? Вспомните известные неудачи XHTML, XForms, SVG, XSLT и т.д. Посмотрите на несколько реализаций этих стандартов, в том числе пиратские и незащищенные авторскими правами продукты. Вы действительно хотите, чтобы эта тенденция сохранилась?

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

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

    1. Любая критика спецификации может быть автоматически отклонена как мелочные придирки. Например, если вам будет предоставлен список из 500 ошибок в 6000-страничной спецификации, вы можете отвечать: "Это меньше, чем 10%. Вы просто придираетесь к мелочам. Мы можем исправить это в версии 1.1". Или вы даже можете просто воспользоваться известным оправданием: "Поставка продукта важнее всего". Любой конечный перечень дефектов может быть сделан незначительным при достаточно большой спецификации.
    2. Далее, поскольку периоды рассмотрения в ISO и в большинстве других организаций стандартов имеют фиксированную длительность, независимо от длины спецификации, достаточно большая спецификация может гарантировать, что ее вообще не будут читать, или только пролистают «по диагонали». Разделите длину спецификации в страницах, на длину периода рассмотрения в днях. Взрослый человек в состоянии прочесть и понять 50 страниц в день. Ваша задача - удвоить или утроить эту нагрузку. 100 страниц в день - хорошее правило для обеспечения того, чтобы добровольцы в Комитете по стандартам не смогли провести тщательное рассмотрение.
    3. Достаточно большой размер спецификации заставит многих думать, что это хорошо проработанный, всеобъемлющий и согласованный документ. Такой же, как налоговое законодательство и федеральный бюджет.
    4. В случае стихийного бедствия спецификация может быть использована в качестве топлива для костра.

    Озаботтесь поиском наиболее подходящей организации по разработке стандартов (ОРС), которая знает, как быстро сделать дело. Критерии оценки включают в себя:

    1. Доказанная способность утверждать стандарты быстро. Вы не заинтересованы в достижении идеального результата. Вы хотите максимально быстро «прокомпостировать свой билет», чтобы вы могли заняться своим бизнесом.
    2. Модель членства, которая эффективно исключает индивидуальных экспертов и проекты с открытым кодом из процесса.
    3. Продемонстрированная компетентность в поддержании необходимой секретности при разработке конфиденциальных стандартов.
    4. Право представлять проекты стандартов в ISO по процедуре Fast-Track.

    Ecma International утвердила стандарты DVD-RAM, DVD-R, DVD+R, DVD-RW и DVD+RW. Хотя некоторые ошибочно утверждают, что эти дублирующиеся стандарты путают потребителей, ясно, что наличие нескольких форматов дало производителям широкие возможности для увеличения продаж мультиформатных DVD-плееров и рекордеров. При наличии единственного формата, разве можно продать более дорогой товар? Ecma четко понимает назначение стандартов и на нее можно положиться.

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

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

    Поскольку положения Устава определяют рамки вашей ответственности, вы должны убедиться, что Устав содержит несколько ограничений, которые вы не захотите обсуждать или отстаивать в будущем. Лучше, чтобы эти ограничения заранее были внесены в Устав, так чтобы вы могли просто сказать: "У нас нет выбора, это наш Устав". Так как ваша задача заключается в описании Единственной Истинной Реализации, хорошее ограничение, которое нужно добавить в Устав, состоит в сосредоточении внимания Технического Комитета на этой единственной задаче. Обходным путем этого можно достичь, потребовав, чтобы разрабатываемая спецификация оставалась 100%-совместимой с другой вашей спецификацией, которая секретна. Таким образом, вы и только вы можете решить, находится ли предлагаемое изменение в рамках Устава. Это обеспечивает большую гибкость и позволяет избежать ненужных дискуссий. "Мы сверились с секретной спецификацией и в ней говорится, что в октябре 40 дней. Извините, парни, но мы ничего не можем сделать. Устав не позволит это нам".

    Несколько дополнительных рекомендаций относительно повседневной работы по описанию Единственной Истинной Реализации:

    • Изучите другие успешные стандарты и процессы, которые привели к ним. Посмотрите на размеры их спецификаций и сколько времени ушло на их разработку. Предположите, что вы сможете спокойно работать со скоростью в 10-20 раз быстрее. Этот темп оправдает преимущество вашей Единственной Истинной Реализации и отсутствие совещаний, дискуссий или рассмотрения альтернатив.
    • Любой ценой не допускайте повторного использования любых существующих стандартов. Повторное использование стандарта приведет лишь к общности, интероперабельности и увеличению повторного использования, и вы рискуете быть вовлеченным в дискуссии с другими организациями по разработке стандартов. Нужно избегать подобной задержки. Единственная Истинная Реализация есть все, что вы или кто-либо другой должен знать. Это истинная fons et origo всей мудрости и знаний.
    • Это также означает, что вы не должны взаимодействовать с другими группами стандартов. Предположите просто, что руководимый вами Технический Комитет является экспертом по всем вопросам. В любом случае, опыт не имеет значения, поскольку вы просто описываете Единственную Истинную Реализацию. Все решения по существу уже были приняты много лет назад. Ваша задача - просто записывать.
    • Секретность имеет первостепенное значение. Если публика узнает, что вы обсуждаете и с какими проблемами вы сталкиваетесь, они могут начать предлагать вам свои мнения или альтернативные варианты. Это так раздражает... Поэтому все заседания, протоколы, списки рассылки и т.д., должны быть сугубо конфиденциальными.

    Вот и все. Остальное, что нужно - просто здравый смысл. Думайте быстро. Думайте взвешенно. Сосредоточтесь на Единственной Истинной Реализации. Свободное применение вышеуказанных принципов должно позволить любому быстро и безболезненно создать Международный Стандарт.

    ecm-discovery.blogspot.com

    ГОСТ 19 и 34 СЕРИИ при оформлении документации

    К списку публикаций

    26.04.2018г.

    ИСПОЛЬЗОВАНИЕ ТРЕБОВАНИЙ ГОСТ 19 и 34 СЕРИИ ПРИ ОФОРМЛЕНИИ ДОКУМЕНТАЦИИ В IT-ПРОЕКТАХ ДЛЯ ГОСУДАРСТВЕННЫХ СТРУКТУР

    Введение

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

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

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

    Определение стандартов оформления документации

    Оформление документов в ГОСТ 34 зависит от вида документа (конструкторский или программный), и стадии создания АС, на которой готовится документ.

    Перечень документов, разрабатываемых на различных стадиях создания АС приведен в ГОСТ 34.201-89 «Виды, комплектность и обозначение документов при создании автоматизированных систем». В нем приведены следующие требования:

    • На стадии «Техническое задание» разрабатывают ТЗ на создание АС по ГОСТ 34.602-89 «Техническое задание на создание автоматизированной системы»;
    • Виды программных документов, разрабатываемых на различных стадиях создания АС определяются по ГОСТ 19.101-77 «Единая система программной документации. Виды программ и программных документов». К ним относятся различные руководства, например, руководство пользователя.
    • Виды конструкторских документов, разрабатываемых на различных стадиях создания АС определяются по ГОСТ 2.102-2013 «Единая система конструкторской документации. Виды и комплектность конструкторских документов». Например, к ним относятся ведомости эскизного и технического проекта, ведомость покупных изделий, пояснительные записки к эскизному, техническому проектам.

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

    Оформление ТЗ

    С ТЗ всё достаточно ясно: в ГОСТ 34.602-89 приведен стандарт его оформления: п.3.2. гласит, что «ТЗ на АС оформляют в соответствии с требованиями ГОСТ 2.105 на листах формата А4 по ГОСТ 2.301 без рамки, основной надписи и дополнительных граф к ней».

    Оформление программной документации

    С программными документами, разрабатываемыми в рамках ИТ-проекта, также есть чёткое указание использовать ГОСТ 19 серии в части оформления: вышеприведённый ГОСТ 19.101-77 входит в серию ГОСТов 19-й серии «Единая система программной документации» (ЕСПД). ЕСПД — комплекс государственных стандартов Российской Федерации, устанавливающих взаимосвязанные правила разработки, оформления и обращения программ и программной документации.

    Документация в ЕСПД оформляется по ГОСТ 19.104-78 «Единая система программной документации. Основные надписи», ГОСТ 19.105-78 «Единая система программной документации. Общие требования к программным документам», ГОСТ 19.106-78 «Единая система программной документации. Требования к программным документам, выполненным печатным способом».

    Оформление конструкторской документации

    Теперь рассмотрим ГОСТ 2.102-2013. Этот стандарт входит в серию ГОСТов 2-й серии «Единая система конструкторской документации» (ЕСКД). ЕСКД — межгосударственный комплекс стандартов, устанавливающих взаимосвязанные нормы и правила по разработке, оформлению и обращению конструкторской документации, разрабатываемой и применяемой на всех стадиях жизненного цикла изделия (при проектировании, изготовлении, эксплуатации, ремонте и др.)

    Документация в ЕСКД оформляется по нескольким стандартам. Наиболее часто используемыми из них (применительно к ИТ-сфере) являются ГОСТ 2.105-95 «Единая система конструкторской документации. Общие требования к текстовым документам» и ГОСТ 2.106-96 «Единая система конструкторской документации. Текстовые документы».

    На первый взгляд из ГОСТ 34 серии непонятно, как оформлять документацию на АС. Нередко в рамках ИТ-проекта, особенно для государственных заказчиков, в ТЗ бывают требования по оформлению документации согласно ГОСТ 2.105-95 и ГОСТ 2.106-96. Но следует ли оформлять документы по этим ГОСТам в случае, если в явном виде требования к оформлению отсутствуют?

    Как правильно оформить?

    В ГОСТ 2-й серии приведены требования к назначению каждого стандарта и обозначена отрасль его применения: ГОСТ 2.102-2013 – стандарт устанавливает виды и комплектность конструкторских документов на изделия всех отраслей промышленности.

    Если ГОСТ 2.102-2013 распространяется на изделия всех отраслей, в том числе и ИТ-сферу, давайте разберёмся, а что является конструкторским документом?

    Согласно ГОСТ 2.001-2013 «Единая система конструкторской документации (ЕСКД). Общие положения»:

    А) «3.1.2 конструкторский документ: Документ, который в отдельности или в совокупности с другими документами определяет конструкцию изделия и имеет содержательную и реквизитную части, в том числе установленные подписи»

    Б) «3.1.5 конструкторская документация: Совокупность конструкторских документов, содержащих данные, необходимые для проектирования (разработки), изготовления, контроля, приемки, поставки, эксплуатации, ремонта, модернизации, утилизации изделия»

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

    Основные ГОСТы 2-й серии для ИТ-проекта в части оформления

    Теперь посмотрим на основные ГОСТы 2-й серии, наиболее часто применяемые для оформления документов в ИТ-проекте. Как правило, в части оформления используют:

    ГОСТ 2.105-95 – стандарт устанавливает общие требования к выполнению текстовых документов на изделия машиностроения, приборостроения и строительства;

    ГОСТ 2.106-96 – стандарт устанавливает формы и правила выполнения конструкторских документов изделий машиностроения и приборостроения.

    У читателя может возникнуть вопрос, можем ли мы применять эти ГОСТы для АС, если они предназначены для изделий машиностроения и приборостроения?

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

    Кроме этого, если заглянуть в ГОСТ 34.003-90 «Автоматизированные системы. Термины и определения», этот стандарт определяет АС как «систему, состоящую из персонала и комплекса средств автоматизации его деятельности, реализующую информационную технологию выполнения установленных функций».

    Таким образом, АС относится к отрасли приборостроения и, следовательно, конструкторские документы АС оформляются по ГОСТ 2.105-95 и ГОСТ 2.106-96.

    Теперь давайте рассмотрим основные моменты оформления проектной документации по ГОСТ 2.105-95 и ГОСТ 2.106-96.

    Основные моменты при оформлении по ГОСТ 2. 105

    Рассмотрим основные параметры оформления по ГОСТ 2-й серии.

    Согласно ГОСТ 2.105-95 расстояние от рамки формы до границ текста в начале и в конце строк должно быть не менее 3 мм. Расстояние от верхней или нижней строки текста до верхней или нижней рамки должно быть не менее 10 мм. Абзацы в тексте начинают отступом, равным пяти ударам пишущей машинки (15 - 17 мм).

    В ГОСТ 2.105-95 не определены параметры для оформления текста в электронном виде: название шрифта, высота шрифта, межстрочный интервал. Поэтому параметры оформления документов в электронном виде это, как правило, предмет договоренности с заказчиком.

    В начале работы по оформлению в электронном виде определяются параметры для форматирования:

    • Формат абзацев текста – используемый шрифт, высота шрифта, размер межстрочного интервала;
    • Формат для каждого заголовка по уровням (1, 2, 3) – используемый шрифт, высота шрифта, отступ в см, размер межстрочного интервала;

    Таблица — используемый шрифт текста, межстрочный интервал, толщина границ таблицы, ширина таблицы, отступ в ячейке, название размещается над таблицей. Форматирование названия Таблицы выполняется таким же образом, как у основного текста документа. По ГОСТ 2.105-95 высота строк таблицы должна быть не менее 8 мм. Высота шрифта строк таблицы также может быть согласована с заказчиком.

    Иллюстрации в документе следует располагать по центру. Название размещается непосредственно под иллюстрацией. Форматирование названия – как у текста документа.

    Правила оформления таблиц

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

    Таблицы, за исключением таблиц приложений, нумеруют арабскими цифрами сквозной нумерацией. Например: «Таблица 1».

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

    Допускается нумеровать таблицы в пределах раздела. В этом случае номер таблицы состоит из номера раздела и порядкового номера таблицы, разделенных точкой. Например, в разделе 4 номер будет «Таблица 4.3».

    Название таблицы должно отражать ее содержание, быть точным, кратким. Название состоит из слова «Таблица», номера таблицы и текста. В ГОСТ 2.105-95 не определено использование в названии таблицы дефиса или тире. На практике может использоваться тире, по аналогии использования в названии рисунка тире. Например, «Таблица 5 – Выполняемые работы, содержание и сроки». Точка в конце названия не ставится. Название размещают над таблицей слева.

    В ГОСТ 2.105-95 в п.п 4.4.3 приведено следущее требование: «На все таблицы документа должны быть приведены ссылки в тексте документа, при ссылке следует писать слово «таблица» с указанием ее номера». На практике слово «таблица» склоняется в тексте по правилам русского языка. Например: «Краткое описание назначения и основных характеристик подсистем ИС МП второй очереди представлено в таблице 1».

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

    В ГОСТ 2.105-95 есть необязательное требование в п.4.4.7: «если в конце страницы таблица прерывается и ее продолжение будет на следующей странице, в первой части таблицы нижнюю горизонтальную линию, ограничивающую таблицу, допускается не проводить.». На практике нижнюю горизонтальную линию, проводят, так ее отсутствие ухудшает восприятие таблицы пользователем.

    Правила оформления иллюстраций

    К иллюстрациям относятся графические изображения (схемы, графики, фотографии, рисунки).

    Иллюстрации, за исключением иллюстраций приложений, нумеруются арабскими цифрами, при этом нумерация сквозная. Например: «Рисунок 3».

    Иллюстрации каждого приложения обозначают отдельной нумерацией арабскими цифрами с добавлением перед цифрой обозначения приложения. Например: «Рисунок В.6».

    Допускается нумеровать иллюстрации в пределах раздела. В этом случае номер иллюстрации состоит из номера раздела и порядкового номера иллюстрации, разделенных точкой. Например, в разделе 5 номер будет «Рисунок 5.2».

    Допускается не нумеровать мелкие иллюстрации (мелкие рисунки), размещенные непосредственно в тексте и на которые в дальнейшем по тексту нет ссылок.

    Требования ГОСТ 2.105-95 к расположению: «иллюстрации могут быть расположены как по тексту документа (возможно ближе к соответствующим частям текста), так и в конце его».

    В ГОСТ 2.105-95 в п. 4.3.1 указано следующее: «при ссылках на иллюстрации следует писать "... в соответствии с рисунком 2" при сквозной нумерации и "... в соответствии с рисунком 1.2" при нумерации в пределах раздела».

    Название пишется под иллюстрацией в формате «Рисунок 1 – Детали прибора».

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

    То есть, если вы что-то распечатали и нашли ошибку, то её можно исправить вручную приведенным выше способом.

    Оформление по ГОСТ 2. 106-96

    ГОСТ 2.106-96 устанавливает формы и правила выполнения конструкторских документов. Для каждого типа документа в ГОСТ 2.106-96 приведен шаблон оформления рамок документа.

    ГОСТ 2.106-96 определяет не только форму рамок, но и основную надпись в рамке. Пример из ГОСТ 2.106-96: «ПЗ составляют на формах 9 и 9а приложения А, а необходимые схемы, таблицы и чертежи в бумажной форме допускается выполнять на листах любых форматов, установленных ГОСТ 2.301, при этом основную надпись и дополнительные графы к ней выполняют в соответствии с требованиями ГОСТ 2.104 (форма 2а)».

    Резюме

    В дополнение к вышесказанному можно сказать, что при разработке АС по ГОСТ 34 в IT-проектах для государственных структур в случае отсутствия точных указаний в государственном контракте или конкурсном ТЗ программная и конструкторская документация должна оформляться по следующим ГОСТам:

    • Программные документы, разрабатываемые на различных стадиях создания АС оформляются по ГОСТ 19.104-78, ГОСТ 19.105-78, ГОСТ 19.106-78;
    • Конструкторские документы, разрабатываемые на различных стадиях создания АС оформляются по ГОСТ 2.105-95 и ГОСТ 2.106-96. При этом требования к содержанию регламентируются РД 50.34-698-90.

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

    К списку публикаций

    www.bazt.ru

    Оформление таблицы по ГОСТу

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

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

     

    Основные правила

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

     

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

    * Нумерация. Каждая таблица должна иметь свой порядковый номер. При этом номера проставляются строго арабскими цифрами. Если в одной главе присутствует несколько таблиц, то они нумеруются следующим образом, Таблица 1, таблица 1. 1 и так далее.

    * Если таблица помещается непосредственно в тексте, то слово «таблица» следует писать полностью. В случае если ее нужно перенести в раздел «приложение», то в тексте уместно использовать сокращенный вариант написания (таб.).

    * Заголовки таблиц прописываются с большой (заглавной) буквы, последующие подзаголовки пишутся с маленькой (строчной) буквы. Если после заголовка ставится точка, то название подзаголовков таблиц пишется с заглавной буквы. В конце названий таблиц знаки препинания (точка) не ставятся.

     

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

     

    1. По ГОСТ стандартам не допускается разделение заголовков и подзаголовков таблиц линиями. Пример: Таблица 1/ диаграмма 2 – это неправильный вариант. Правильный вариант – Таблица 1. Диаграмма 2.

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

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

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

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

    6. Если в какой-либо графе отсутствуют числовые показатели, то напротив наименования

    7. Размер величин, нуждающихся в примере, оформляются после заголовка определенной строки и пишутся после них, через запятую.

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

    9. Если цифровой материал можно перенести в текст, то его лучше оформлять в виде текстового документа, а не в таблицы.

     

    Текст в таблице

    1. Текст в таблице начинается с прописной буквы (заглавной). Исключение в этом правиле является приведение текста как образца и то, только в том случае, если первое слово не является собственным.

    2. Если основное слово существительное, то оно должно стоять в именительном падеже.

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

     

    Оформление числовых изображений

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

    Если числовые значения имеют однородную величину, то единицы проставляются под единицами, десятки под десятками и так далее. Неоднородные величины ставятся посередине. Пример: 5600

     25,6

     5,8

    При необходимости указать диапазон величин, то между показателями ставится тире. Пример: 200 – 500; 1000 – 1500.

     

     

     

    prostudenta.ru

    Документирование по ГОСТ 34* — это просто / Хабр

    Сегодня мы поговорим об отечественных стандартах на проектную документацию. Как эти стандарты работают на практике, чем они плохи и чем хороши. При разработке документации для государственных и серьезных частных заказчиков у нас обычно нет выбора — в требования по документированию ТЗ вписано соблюдение стандартов. На практике мне приходилось сталкиваться с различными примерами недопонимания структуры стандартов, того, что должно быть в документах и зачем эти документы нужны. В итоге из-под пера техписателей, аналитиков и специалистов выходят порой такие перлы, что непонятно, в каком состоянии сознания они писались. А ведь на самом деле все достаточно просто. Поиск по Хабру не вернул ссылок на более-менее целостный материал на данную тему, потому предлагаю закрасить этот досадный пробел.
    Что такое стандарты на документацию?
    В серии 34, о которой идет речь, существует всего 3 основных стандарта по документированию:

    ГОСТ 34.602-89 Техническое задание на создание автоматизированной системы

    Самый любимый и популярный стандарт по разработке ТЗ. Единственное, не стоит забывать, что он крепко связан с другими стандартами серии и если вы получили ТЗ, выполненное по данному стандарту, крайне желательно придерживаться и других стандартов, даже если об этом нет прямых требований. Хотя бы в плане общей идеологии (о которой ниже)

    ГОСТ 34.201-89 Виды, комплектность и обозначения документов при создании автоматизированных систем

    Это базовый документ, в котором приводится полный перечень документации ГОСТ 34, рекомендации по кодированию документов, к каким стадиям проекта относятся документы (стадии описываются в ГОСТ 34.601-90), а также как их можно объединить между собой.

    Фактически, этот стандарт представляет собой большую таблицу с комментариями. Ее можно загнать в Excel для удобства использования.

    РД 50-34.698-90 Автоматизированные системы. Требования к содержанию документов

    Объемистый стандарт, с различной степенью детальности описывающий содержание проектных документов. В качестве индекса используется упомянутый выше ГОСТ 34.201-89.

    К стандарту РД 50-34.698-90 существует множество вопросов и трактовок его положений, которые ввиду их неконкретности, часто понимают по-разному заказчик и исполнитель или даже члены проектной команды. Но ничего более конкретного у нас, к сожалению, нет.

    Рассмотрим теперь плюсы и минусы стандартов, начав традиционно с минусов.

    Минусы стандартов
    Основной минус всем очевиден — стандарты старые. В них заложено устаревшее представление об архитектуре автоматизированной системы. Например:
    • приложения двухуровневые, состоящие из клиентской программы и сервера СУБД (никаких трех- и более «уровневых» приложений, никаких Weblogic или JBoss)
    • структура таблиц базы данных, будучи описана, даст представление о логической модели данных (то, что между приложением и базой может находиться какой-нибудь Hibernate, тогда казалось нехорошим излишеством)
    • пользовательский интерфейс однооконный (а разве бывает другой? А что такое «браузер»?)
    • Отчетов в системе немного, все они бумажные и печатаются на матричном принтере
    • Разрабатываемая программа ориентирована на решение «задачи обработки информации», которая имеет четкий вход и выход и узко специализирована. В основе обработки информации лежит «алгоритм». Иногда «алгоритмов» бывает несколько. (Объектно-ориентированное программирование тогда делало лишь свои первые шаги и серьезно не рассматривалось).
    • администратор базы данных понимает, какая информация лежит в таблицах и активно участвует в редактировании системных справочников (а разве бывает один сервер СУБД для 50 разных приложений?)
    Соответственно, в стандарте есть артефакты, наподобие следующего:

    5.8. Чертеж формы документа (видеокадра) В документе должно быть приведено изображение формы документа или видеокадра в соответствии с требованиями государственных стандартов унифицированной системы документации Р 50-77 и необходимые пояснения. Смысл документа в том, что на советских предприятиях использовались так называемые «Участки печати», где стояли матричные скоростные принтеры, драйверы к которым часто писали сами инженеры. Поэтому они должны были поддерживать реестр всех документов, которые требовалось печатать для гарантии того, что в напечатанном виде документы будут выглядеть так, как положено.

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

    Сейчас уже нам ничего не говорят слова «машинограмма», «видеокадр», «АЦПУ». Я тоже их не застал в употреблении, хотя заканчивал профильный институт в 90-е. Это было время появления Windows 3.1, VGA дисплеев, трехдюймовых дискет и первых отечественных интернет-сайтов. Но в стандарте эти слова есть, и заказчик иногда капризно требует предоставить ему полный комплект документации в соответствии с ГОСТ 34.201-89. Более того, подобные формулировки в ТЗ кочуют из одного министерства в другое и стали уже неким негласным шаблоном, в который вбивают содержательную часть.

    Так что документ с дурацким названием «Чертеж формы документа (видеокадра)» в проекте должен быть и должен быть не пустым.

    Что в стандарте хорошо

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

    А стандарты ГОСТ 34 хороши еще и тем, что они составлялись умными людьми, обкатывались годами и у них есть четкая цель — максимально полно описать на бумаге сложную абстрактную сущность, которую представляет собой любая АСУ.

    Когда вам требуется грамотно поставить задачу западным подрядчикам, которые про наши ГОСТы слыхом не слыхивали, можно также опираться на эти стандарты, а точнее на их контент, смысловую составляющую. Потому что, повторюсь, гарантия полноты информации дорогого стоит. Как бы мы себя не тешили высоким уровнем своего профессионализма, мы можем забыть включить в состав наших требований элементарные вещи, тогда как тот же ГОСТ 34.602-89 «помнит» обо всем. Если вам непонятно, как должен выглядеть результат работы западных подрядчиков, посмотрите на требования к документированию, к рекомендуемым разделам. Уверяю вас, лучше не придумать! Скорее всего, есть западные аналоги наших стандартов, в которых все может быть полнее, современнее и лучше. К сожалению, я с ними не знаком, так как не было пока ни одного случая, чтобы наших ГОСТов было бы недостаточно.

    Можно смеяться над тем, что создатели стандартов ничего не знали о java или .NET, о HD мониторах и Интернете, но я бы не советовал недооценивать масштаб проделанной ими работы и ее ценность для нашего профессионального сообщества.

    Как читать и понимать стандарты документации по ГОСТ серии 34

    Стандарт делит все документы по двум осям — время и предметная область. Если посмотреть таблицу 2 в ГОСТ 34.201-89, то хорошо видно это деление (колонки «Стадия создания» и «Часть проекта»

    Стадии создания АСУ
    Стадии создания определены в ГОСТ 34.601-90. Имеют отношение к документированию из них три:
    • Эскизный проект (ЭП)
    • Технический проект (ТП)
    • Разработка рабочей документации (РД)
    Эскизный проект следует после стадии Техническое задание и служит для разработки предварительных проектных решений.

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

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

    Части (разделы) проектной документации по созданию АСУ
    Предметная область разделена на «Обеспечения». Поначалу кажется, что такое деление избыточно и ненужно. Но когда начинаешь на практике работать этим инструментарием, постепенно доходит вложенная в него идеология.

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

    Для того, чтобы полностью описать этот «автомат», сделаны следующие разрезы (как в черчении):

    Математическое обеспечение (МО), отвечающее на вопросы: какая логика зашита внутри «черного ящика»? Почему выбраны именно эти алгоритмы, именно такие формулы и именно такие коэффициенты?

    Математическое обеспечение ничего не знает ни о процессорах, ни о базах данных. Это отдельная абстрактная область, обитель «сферических коней в вакууме». Но математическое обеспечение бывает очень плотно связано с предметной областью, aka Реальная жизнь. Например, управляющие алгоритмы для систем управления дорожным движением требуется согласовать в ГИБДД перед тем, как их будет согласовывать заказчик. И тут понимаешь, зачем их выделяют в отдельную книжицу. Потому что в ГИБДД никому не интересно, на какой ОС будет работать сервер приложения, а вот какой знак и ограничение скорости выскочит на табло в дождь или в снег очень даже интересно. Они отвечают за свою часть, и ничего другого подписывать не собираются. С другой стороны, когда они подписали, не будет вопросов к технической стороне вопроса — почему выбрали те, а не другие табло или светофоры. Мудрость «предков» как раз и проявляется в таких вот практических кейсах.

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

    Или вот «Ведомость машинных носителей информации». Понятно, что раньше в нем были номера магнитных барабанов или бобин с пленкой. А сейчас что туда вносить?

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

    Программное обеспечение (ПО). Любимая всеми часть проектной документации. Да хотя бы потому, что это всего один документ! И потом, всем понятно, что туда нужно записывать. Но я, все-же, повторю.

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

    Техническое обеспечение (ТО). Не менее любимая всеми часть проектной документации. Радужную картину омрачает только обилие документов, которые требуется разрабатывать. Всего по стандарту требуется разработать 22 документа, из них 9 на стадии ТП.

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

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

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

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

    На стадии РД появляются другие, более интересные документы, которые мне бы хотелось рассмотреть отдельно.

    Руководство пользователя. Комментарии излишни, я думаю.

    Методика (технология) автоматизированного проектирования. В этот документ при необходимости можно поместить описание процесса сборки ПО, управления версиями, тестирования и т.п. Но это если в ТЗ заказчик желает самолично осуществлять сборку ПО. Если он этого не требует (и не платит за это), то вся ваша внутренняя кухня не его ума дело, и этот документ делать не нужно.

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

    Описание бизнес-процессов, ролевые и должностные инструкции, регламенты работы — все это ОРД, то есть организационно-распорядительная документация. Которая является продуктом консалтингового проекта, который у вас, насколько я понимаю, не покупали. А покупали у вас проект технический и документацию к нему тоже техническую.

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

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

    Описание технологического процесса обработки данных (включая телеобработку). Жалкий рудимент пещерного века, когда были специально выделенные «Операторы ЭВМ», скармливающие машине перфокарты и упаковывающие распечатку результата в конвертик. Эта инструкция — для них. Что в нее писать в XXI веке — я вам точно сказать не могу. Выкручивайтесь сами. Самое лучшее, это просто забыть про этот документ.

    Общесистемные решения (ОР). Стандартом предусмотрено 17 документов раздела ОР. Во-первых, это почти все документы предварительной фазы Эскизного проектирования. Во-вторых, это всевозможные сметы, расчеты и краткие описание автоматизируемых функций. То есть, информация для людей не с основного ИТ-производства, а для вспомогательного персонала — менеджеров, сметчиков, специалистов по закупкам, экономистов и т.п.

    А в-третьих, в состав ОР входит мега-документ под названием «Пояснительная записка к техническому проекту», который по задумке представляет собой некий Executive Summary, а по факту многие проектанты пихают в него вообще все полезное содержание стадии ТП. Подобный радикальный подход бывает оправдан и даже взаимно выгоден и заказчику и исполнителю работ, но в определенных случаях.

    Варианты использования ГОСТ 34

    1. Полное и точное следование стандарту. Добровольно никто, естественно, такую тучу документов писать не будет. Поэтому полный комплект документов готовится только по настоятельной просьбе заказчика, которую он закрепил в ТЗ и еще договором сверху придавил. В таком случае требуется понимать все буквально и отдать заказчику физические «книжки», на которых будут стоять названия документов из таблицы 2 ГОСТ 34.201-89 за исключением совсем уж ненужных, перечень которых вы обязательно должны обговорить и закрепить письменно. Содержание документов также должно без всякой фантазии соответствовать РД 50-34.698-90, вплоть до названия разделов. Для того, чтобы у заказчика взорвался мозг, иногда большую систему делят на подсистемы, и для каждой подсистемы выпускают отдельную проектную документацию. Выглядит это устрашающе и нормальному контролю при помощи земного разума не подлежит. Особенно в части интеграции подсистем. Что значительно упрощает приемку. Главное, чтобы вы сами при этом не запутались и чтобы ваша система все-таки заработала как надо.
    2. Мы просто любим ГОСТы. В серьезных больших компаниях любят стандарты. Потому, что они помогают людям лучше понимать друг друга. Если ваш заказчик замечен в любви к порядку и стандартизации, постарайтесь придерживаться стандартной идеологии ГОСТ при разработке документов, даже если этого не требует ТЗ. Вас лучше поймут и одобрят согласующие специалисты, а вы сами не забудете включить в документацию важную информацию, лучше будете видеть целевую структуру документов, точнее планировать работы по их написанию и сэкономите себе и коллегам массу нервов и денег.
    3. Нам плевать на документацию, лишь бы все работало. Исчезающий вид безответственного заказчика. Подобный взгляд на документацию пока еще можно встретить у небольших и бедных заказчиков, а также в оставшихся со времен перестройки авторитарных «идиотократиях», где босс окружен верными друзьями — директорами, и все вопросы решаются в личных беседах. Вы вольны в подобных условиях забивать на документирование вообще, но лучше, все таки, прицел не сбивать и хотя бы схематично наполнять содержимым документацию. Если не этому заказчику, так следующему передадите (продадите).
    Заключение

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

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

    habr.com

    Оформление приложений к документам | Статьи

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

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

    Оформление приложений к документам по всем правилам

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

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

    В первом случае сопроводительное письмо и документы-приложения составляют единый комплект документов, во втором случае основной документ и документы-приложения являются частями одного документа.

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

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

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

    Правила оформления отметки о наличии приложений установлены ГОСТ Р 6.30-2003 “Унифицированные системы документации. Унифицированная система организационно-распорядительной документации. Требования к оформлению документов” (далее – Стандарт). И хотя Стандартом предусмотрено несколько вариантов оформления отметки, на практике встречаются ситуации, не предусмотренные стандартом. В связи с этим имеет смысл рассмотреть все ситуации, как предусмотренные, так и не предусмотренные Стандартом.

    Ситуации оформления приложений, предусмотренные Стандартом

    1. Если документ-приложение назван в тексте, отметку о наличии приложения оформляют следующим образом:

    Приложение: на 5 л. в 2 экз.

    Если письмо имеет приложение, не названное в тексте, то в отметке о наличии приложения указывают его наименование, количество листов и количество экземпляров, а при наличии нескольких приложений их нумеруют, например:

    Приложение: 1. Положение об Управлении регионального кредитования на 5 л. в 1 экз.
    2. Правила подготовки и оформления документов Управления регионального кредитования на 7 л. в 2 экз.

    Если приложения сброшюрованы, то количество листов не указывают. Например, если документ-приложение назван в тексте:

    Приложение: в 1 экз.

    Приложение: 1. Положение об Управлении регионального кредитования на 5 л. в 1 экз.
    2. Правила подготовки и оформления документов Управления регионального кредитования на 7 л. в 2 экз.

    или если документ-приложение не назван в тексте:

    Приложение: Каталог запасных частей к стиральным машинам Samsung в 1 экз.

    Если к документу прилагается другой документ, также имеющий приложения, отметку о наличии приложения оформляют следующим образом:

    Приложение: письмо Росархива от 05.06.2010 № 02-6/172 и приложение к нему, всего на 3 л.

    Если приложение направляют не во все указанные в документе адреса, а только первому (основному) адресату, отметку о приложении оформляют следующим образом:

    Приложение: на 3 л. в 5 экз. только в первый адрес.

    Нестандартные ситуации оформления приложений к сопроводительным письмам

    Как уже было сказано, на практике возникают ситуации, оформление которых не предусмотрено Стандартом. Рассмотрим их.

    1. В качестве приложений к сопроводительному письму могут пересылаться документы на бумажном носителе и на электронных носителях (дискетах, дисках CD, DVD, флеш-картах). В этом случае отметка о наличии приложений может быть оформлена следующим образом:

    Приложение: 1. Проект договора поставки электротехнической продукции на 3 л. в 1 экз.
    2. То же на компакт-диске в 1 экз.

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

    Если с сопроводительным письмом пересылается только документ на электронном носителе, отметку о приложении можно оформить следующим образом:

    Приложение: Проект договора поставки электротехнической продукции на компакт-диске в 1 экз.

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

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

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

    Приложение: Экспертное заключение о готовности инфраструктуры к разработке месторождений нефти на шельфе Баренцева моря № 24/1 КТ, коммерческая тайна, на 25 л. в 1 экз.

    Отметка о приложении, когда документ и приложение связаны содержанием

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

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

    Как правило, при оформлении основного документа в соответствующем пункте документа делается ссылка на приложение. Приведем в качестве примера текст распорядительного документа.

    Оформление с одним приложением

    Оформление с несколькими приложениями

    Соответственно, на каждом приложении к основному документу оформляется отметка о приложении по форме, установленной ГОСТ Р 6.30-2003:

    Приложение 2 к приказу Росархива от 15.03.201 1 №35

    Слово “приложение” может печататься прописными буквами со знаком № , допускается также центрировать строки реквизита относительно самой длинной строки:

    ПРИЛОЖЕНИЕ № 1 к приказу Минздравсоцразвития России от 15 апреля 201 1 г. № 133

    Аналогичным образом оформляются приложения к договорам, актам, планам, отчетам и другим документам, например на приложении к договору:

    Приложение № 1 к договору купли-продажи сырой нефти от 05 июля 2011 г. №38/93

    Если приложением к документу является документ, утверждаемый распорядительным документом (например, приказом), то наряду с отметкой о приложении на утверждаемом документе-приложении должен быть еще и гриф утверждения. Поскольку гриф утверждения также содержит ссылку на основной документ (например, приказ), Методическими рекомендациями по разработке инструкций по делопроизводству в федеральных органах исполнительной власти (утв. приказом Росархива от 23.12.2009 № 76) предусмотрено следующее.

    Если приложением к документу (например, к приказу) является утверждаемый документ (положение, правила, инструкция, регламент и др.), в верхнем правом углу проставляется отметка о приложении, ниже – гриф утверждения документа, например:

    Приложение № 1 УТВЕРЖДЕНО приказом Росархива от 12.11.2009 №125

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

    В.Ф. Янковая, канд. ист. наук, доц., зам. директора ВНИИДАД

    www.sekretariat.ru