Гост это требования или рекомендации

Гост это требования или рекомендации

Откуда: Казань
Сообщений: 1518

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

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

ps Если у кого есть ссылки на эту тематику — буду очень признателен.

Откуда: Страна непреодолимых противоречий
Сообщений: 8561

Смотря какие ГОСТ-ы.

Если на ТЗ, ПМИ и оформления документов — по почему бы их и не использовать? Вполне логично все в ГОСТ-ах написано.

Откуда: Казань
Сообщений: 1518

ГОСТ 34.201-89, ГОСТ 34.601-90

Откуда: Страна непреодолимых противоречий
Сообщений: 8561

Да ну, вот эти — бесполезный архаизм.

ГОСТ и РД — вообще то не такая уж и плохая штука. К примеру

РД 50-34.698-90
ГОСТ 34.602-89

Вполне адекватны, и аналогов, в общем то, не имеют (всякие ADM, RUP, PMBOOK и прочие буржуинские мотивы — это несколько не то, для внутреннего рынка).

ГОСТ 7.32-2001 (он же ГОСТ 7.32-91, он же ДСТУ 3008-95, он же ISO 5966) — вообще обязателен
к исполнению (повбывав бы некоторых за неправильные обозначения и ссылки в тексте).

А вообще, что за паника? Стандарт есть стандарт, хоть ГОСТ, хоть ANSI, хоть ISO, хоть какой BIP, DIN).

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

Откуда:
Сообщений: 45

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

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

ps Если у кого есть ссылки на эту тематику — буду очень признателен.

Статья 47 ФЗ «О техническом регулировании» признаёт утратившим силу ФЗ «О стандартизации» от
1993 г. Соответственно, в общем случае ГОСТы как обязательные нормативные акты свою силу утратили.
Однако, они продолжают действовать в ряде специфических предметных областей, например в сфере гособоронзаказа, в медицине и ещё кое где — там, куда действие упомянутого ФЗ «О техническом регулировании» не простирается.

Мораль — зависит от того, кто у Вас заказчик.

Откуда: Москва
Сообщений: 278

Яркий пример «ура-патриотизма» в приложении к информационным технологиям. «Чув звiн, та не знаю де вiн» (с) украинская пословица.
Из всего перечисленного вами «буржуинского», вы не привели ни одного АНАЛОГА того же ГОСТ 34.602. А именно — ГОСТ это стандарт, а то что привели вы — это методологии и своды знаний (кстати, PMBOK, а не PMBOOK, и он несколько не о том, что и ГОСТ 34-й серии). Отсюда и необоснованность утверждения, что «буржуинские мотивы — это несколько не то, для внутреннего рынка», особенно если заглянуть еще и сюда http://secr.ru/2006/upload/files/63.pdf

Типичный пример нынешнего отношения, особенно в госструктурах — «важно не содержимое документа, а размер отступа и шрифт» . а ТЗ как возьмешь почитать . Таким образом все полезное что есть в ГОСТ на тему представления информации подменяется ОФОРМЛЕНИЕМ!

Откуда: Страна непреодолимых противоречий
Сообщений: 8561

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

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

Откуда:
Сообщений: 145096

> ГОСТы, описывающие ТЗ, процесс разработки, внедрения и прочее по теме, достойны того,
> чтобы с ними ознакомиться

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

Откуда:
Сообщений: 145096

> от госзаказов, кстати, я бы не советовал отмахиваться

А я бы ни в коем случае не рекомендовал с ними связываться. По целому ряду причин.

Откуда:
Сообщений: 145096

> Вы излишне категоричны

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

> Соблюдая некоторые несложные правила техники безопасности

Нет проблем. Но, поскольку предупреждали, потом следует обижаться только на себя.

Откуда:
Сообщений: 145096

Откуда: Москва
Сообщений: 278

1. Обрызгали — обтекай, не умеешь обтекать — впитывай (с) :-). А понятно то, что буржуинских стандартов ТЫ (раз уж мы на «ты») не знаешь, да и с ГОСТами я не понял насколько хорошо знаком. Вот и получается, что «Пастернака я не читал, но осуждаю» :-), это и возмущает больше всего.
2. Связь очевидна содержание первично, оформление вторично, и то, если требуют.

Да абсолютно пофиг, я не националист .
лучше погугли на тему PMBOK :-), наука она не в лес, а в голову.

В ТЗ есть пункт «Требования к программной документации». В нем должны быть оговорены требования к составву и содержанию документов (по ЕСПД, ЕСКД или свободный (коммерческий) формат и т. п.) и их представлению в электронном виде (dос, pdf, html и т. п.).
Это надо согласовать обязательно, чтобы потом не было недоразумений.
Бюджетные организации, как правило, требует соблюдения ГОСТов.
Бюджетные организации Минобороны, у которых есть военная приемка, требуют ОБЯЗАТЕЛЬНОГО соблюдения ГОСТов.

Откуда: Страна непреодолимых противоречий
Сообщений: 8561

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

P.S. А PMBOOK — согласен, отличное чтиво на ночь. В качестве снотворного. В качестве смехотворного и слабительного — тоже, вполне себе ничего.
Прямо наука, куда уж там. Вникайте дети, сейчас нам тут крутой independed кАнсалтер расскажет, что, почём и как. 😉

P.P.S. Резюме в профиле — да, повеселило.. не можешь сам — учи как надо. Не можешь учить, учи как надо учить?

Откуда: Москва
Сообщений: 278

Хорошо смеется тот, кто смеется . 🙂 инкогнито вы наш :-), пишущий на Дельфи+Оракл . а все туда же, хлебом не корми, дай порассуждать про RUPы да PMBOKи, о коих не сведущ.

Откуда: Казань
Сообщений: 1518

Спасибо за ответ! Буду изучать указанный документ.

Откуда: Москва
Сообщений: 278

О . это благодатная тема. Возможно вам следует подумать о разработке собственного корпоративного стандарта для документирования создаваемого как собственными силами, так и субподрядчиками ПО. Основная мысль — документация должна быть ЭФФЕКТИВНОЙ. Для этого нужно помимо собственно шаблонов документов, делать некоторые методические рекомендации по тому как разрабатывать эти документы. У меня есть определенный опыт в этой области — если интересно — welcome в личку — мой e-mail в профиле.

Тогда вам, как говорится, «карты в руки».
У вас есть три варианта;
1 Предложить разработать и оформить документацию по какому- либо ГОСТу (ЕСПД, ЕСКД и т. п). В этом случае самим делать ничего не надо.
2 Предложить разработать и оформить документацию по ВАШЕМУ СОБСТВЕННОМУ корпоративному стандарту. В этом случае, естественно, надо иметь такой стандарт.
3 Разработку и оформление отдать на усмотрение исполнителя. В этом случае самим делать ничего не надо.

Последствия:
1 и 2 вариант — вся последующая документация будет разрабатываться и оформляться в едином стиле. («Фирменный стиль»).
3 вариант — получите «зоопарк» разных видов и форматов документации (если это разные исполнители).

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

Откуда: Казань
Сообщений: 1518

Гост это требования или рекомендации

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

Что такое стандарты на документацию?

В серии 34, о которой идет речь, существует всего 3 основных стандарта по документированию:

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

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

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

Объемистый стандарт, с различной степенью детальности описывающий содержание проектных документов. В качестве индекса используется упомянутый выше ГОСТ 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. Нам плевать на документацию, лишь бы все работало. Исчезающий вид безответственного заказчика. Подобный взгляд на документацию пока еще можно встретить у небольших и бедных заказчиков, а также в оставшихся со времен перестройки авторитарных «идиотократиях», где босс окружен верными друзьями — директорами, и все вопросы решаются в личных беседах. Вы вольны в подобных условиях забивать на документирование вообще, но лучше, все таки, прицел не сбивать и хотя бы схематично наполнять содержимым документацию. Если не этому заказчику, так следующему передадите (продадите).

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

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

Что такое ГОСТ и зачем он нужен?

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

Система ГОСТов была разработана и запущена еще в СССР. С 1992 года государственный стандарт Российской Федерации имеет обозначение ГОСТ Р. Он подтверждает, что продукция прошла проверку и отвечает всем требованиям безопасности. В 2003 году государственные стандарты, принятые Госстандартом России до 1 июля 2003 года, признаны национальными.

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

Чем ГОСТ отличается от ОСТ?

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

Чем отличается ГОСТ от ТУ?

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

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

Чем ГОСТ отличается от технического регламента?

В 2003 году в России был принят закон «О техническом регулировании», который определяет понятие технического регламента с целью защиты жизни или здоровья граждан, а также предупреждения действий, вводящих в заблуждение приобретателей. Технический регламент устанавливает обязательные условия хранения, перевозки, реализации товаров. Основное отличие ГОСТа от технического регламента состоит в том, что первый характеризуется количественными параметрами выпускаемой продукции, а второй — условиями использования готового изделия. Обязательное применение того или иного ГОСТа или отдельного его раздела (положения) указывается в техническом регламенте.

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

Термин «стандартизация» происходит от английского слова Standard, т.е. норма, образец, основа.

Началом стандартизации на Руси считается 1555 г., когда были введены стандартные калибры-кружала для измерения пушечных ядер.

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

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

Государственный комитет РФ по стандартизации, сертификации и метрологии (Госстандарт России) — как федеральный орган исполнительной власти в области стандартизации исполняет следующие функции:

— разрабатывает предложения по приоритетным направлениям развития работ;

— разрабатывает, выступает государственным заказчиком федеральных программ;

— разрабатывает и вносит проекты федеральных законов и иных нормативных правовых актов;

— организует выполнение научно-исследовательских и опытно-конструкторских работ в закрепленных областях деятельности;

— устанавливает правила проведения работ, государственного контроля и надзора;

— организует проведение работ по межведомственной унификации продукции;

— организует и координирует обеспечение единства измерений;

— принимает и вводит в действие Государственные стандарты РФ;

— устанавливает правила применения в России международных, национальных стандартов, правил, норм и рекомендаций по стандартизации;

— осуществляет государственную регистрацию нормативных документов и т.д.

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

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

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

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

Смотрите так же:  Доверенность ип в суд бланк

Государственные стандарты РФ (ГОСТ Р) являются новым видом национального стандарта, утверждаются Госстандартом России и действуют на всей территории РФ.

Межгосударственные стандарты (ГОСТ) — это стандарты, принятые государствами, подписавшими Соглашение о проведении согласованной политики в области стандартизации, метрологии и сертификации.

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

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

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

— стандарты на продукцию;

— стандарты на процессы;

— стандарты методов испытаний.

Важнейшими целями стандартизации являются:

— достижение оптимального уровня по качеству продукции и повышение ее конкурентоспособности;

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

— повышение уровня безопасности объектов с учетом риска возникновения чрезвычайных ситуаций природного и техногенного характера;

— обеспечение экологической безопасности;

— рациональное и экономное использование ресурсов;

— обеспечение взаимозаменяемости продукции.

Основные задачи стандартизации:

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

— обеспечение взаимопонимания между разработчиками, изготовителями, продавцами и потребителями (заказчиками);

— внедрение прогрессивных технологических процессов;

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

— разработка и установление метрологических норм, положений и требований;

— создание и ведение систем классификации и кодирования технико-экономической информации;

— нормативно-техническое регулирование процесса контроля, сертификации и оценки качества продукции.

Стандарты всех категорий имеют соответствующие обозначения, которые состоят из индекса, регистрационного номера и года принятия (ГОСТ Р 51121—97). Обозначение технических условий состоит из индекса (ТУ), кода группы продукции по классификатору продукции (ОКП), трехразрядного номера, кода предприятия—разработчика, года утверждения. ГОСТ Р, ОСТ и другие равнозначные документы, которые принимаются государственными органами управления, являются официальными. Информацию о действующих государственных стандартах, сроках их действия, изменения к ним можно получать через готовые и ежемесячные информационные указатели «Государственные стандарты РФ».

Правила и требования к оформлению дипломной работе. ГОСТ. Методические указания и рекомендации

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

Общие требования к оформлению дипломной работы по ГОСТУ

В соответствии с упомянутым выше ГОСТом к оформлению дипломной работы предъявляются следующие требования.

Внимание! Если вы сомневаетесь в своих силах, то закажите помощь в написании диплома у профессионалов.

Печать работы выполняется односторонним методом на листах бумаги формата А4.

Текст работы форматируется следующим образом:

  • рекомендуемый шрифт: Times New Roman (в ГОСТе тип шрифта не прописан, однако подавляющее большинство образовательных учреждений используют именно его). При этом ГОСТ допускает использование дополнительного шрифта при выделении каких-либо терминов, формул и т.п.;
  • размер шрифта основного текста (для его обозначения используется термин кегль): не менее 12 (наиболее распространён 14);
  • выравнивание текста: по ширине;
  • междустрочный интервал: 1,5 строки;
  • размеры полей страницы: левое – не менее 3 см, правое – не менее 1 см, нижнее и верхнее – не менее 2 см (ввиду того, что в каждом университете данный параметр зачастую различается, размер полей лучше уточнять в методических указаниях ВУЗа, в котором будет сдаваться работа);
  • абзацный отступ первой строки: 1,25 см.

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

При написании названий печатных материалов (журналов, статей, монографий и т.п.) используются кавычки формата «…..», а при цитировании формата “…..”.

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

Правила оформления заголовков в дипломе

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

Правила ГОСТа и стандарты, применяемые в большинстве ВУЗов:

  • Нумерация разделов обязательна и оформляется с использованием арабских цифр;
  • Нумерация структурных элементов работы (глава, подглава и пункт) производится без точки в конце;
  • Кроме того точка не ставится и после самого заголовка;
  • Величина расстояния между текстом структурной части и заголовком должна равняться 15 мм (при 1,5 интервале это одна пустая строка). Заголовок раздела отделяется от заголовка подраздела расстоянием в 8 мм;
  • При использовании в заголовке какого-либо уточнения (например «глава 1») после номера ставится точка;
  • Заголовки структурных элементов работы печатаются с новой страницы.

Пункты правил ГОСТа, отличающиеся в каждом конкретном ВУЗе:

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

Пример оформления заголовков дипломной работы:

1 Роль Интернета и возможности его применения в исторических исследованиях и образовании

Глава 1. Оценка информации о периоде ВКЛ, размещённой на ресурсах по истории Беларуси

1 Генезис развития международного института прав человека

1.1 Понятие и источники международного права по правам человека

Права человека и гражданина – явление социально-историческое…..

Оформление содержания дипломной работы

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

Образец оформления содержания дипломной работы

1 Теоретические аспекты интернет – рекламы.. 7

1.1 Особенности рекламы туристического продукта в сети Интернет. 7

1.2 Основные направления использования Интернета в целях рекламы туристических услуг. 13

1.2.1 Создание сайта турфирмы.. 13

1.2.2 Привлечение посетителей на сайт рекламодателя. 16

2 Анализ влияния интернет – рекламы на турбизнес Российской Федерации (на примере турагентств г.Смоленска. 21

2.1 Развитие интернет-рекламы туристических услуг в г. Смоленске. 21

2.2 Анализ механизмов продвижения туристических услуг турагентства «Велл» в Интернете. 26

3 Оптимизация сайта турагентства «Велл». 40

Список использованных источников. 57

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

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

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

Кроме этого, исходя из современных требований ВУЗов, иллюстрации также должны иметь и название (подпись под рисунком будет иметь такой вид «Рисунок 2.2.1 – Главная страница исследуемого сайта»). Если работа содержит только одну иллюстрацию, то она нумеруется просто как «Рисунок 1». Если иллюстрация не принадлежит автору, а взята из какого-либо источника, то под названием рисунка курсивным шрифтом указывается источник изображения.

Правила оформления иллюстраций дипломной работы, образец:

Рисунок 1.2 Пример правильного оформления иллюстрации

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

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

  • Нумерация оформляется также как и у иллюстраций – арабскими цифрами по порядку в пределах раздела. К примеру, «Таблица 2.3» – третья таблица во втором разделе;
  • Если таблица располагается в основной части работы, то она должна размещаться непосредственно после абзаца, в котором она была впервые упомянута;
  • Допускается оформление таблиц в приложении. В таком случае нумерация будет вестись отдельно, без указания номера раздела;
  • Если дипломная работа содержит только одну таблицу, то она обозначается как «Таблица 1»;
  • Как и в случае с иллюстрациями, слово «Таблица» нельзя сокращать;
  • Кроме номера, таблица может содержать название (более того, это обязательное требование большинства ВУЗов). Название пишется после номера таблицы, точка в конце не ставится. Например, «Таблица 4.3 – Определение целевых групп»;
  • Наименование таблицы размещается слева над самой таблицей, без использования абзацного отступа;
  • Если таблица не помещается на одной странице, то название проставляется только над её первой частью, а нижняя граница таблицы не проводится;
  • В работе должны быть проставлены ссылки на все размещённые в дипломе таблицы;
  • Если таблица составлена самостоятельно, то под ней курсивным шрифтом указывается источник, с помощью методики которого составлялась данная таблица либо указывается, что это «Собственная разработка». Если таблица заимствована, указывается ссылка на источник вплоть до номера страницы.

Дипломная работа образец оформления таблиц:

Таблица 3.3 – Статистика запросов основных поисковых систем