Гост концепция автоматизированной системы

Традиционные ИТ-стандарты. ГОСТ 34

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

Тридцать четвертым ГОСТом на жаргоне ИТ-специалистов называется совокупность взаимосвязанных стандартов, которые имеют номер, начинающийся на 34: ГОСТ 34.602-89, 34.003-90, 34.603-92, 34.201-89, 34.601-90, 34.698-90, 34.320-96, 34.321-96, а также руководящий документ РД 50-34.698-90 и два стоящих особняком стандарта, относящихся к узкоспециальной теме криптозащиты — ГОСТ 34.10 -01 и ГОСТ 34.11-94.

Все эти стандарты появились в конце 80-х — начале 90-х годов (год выпуска обозначен числом после дефиса), заменив или дополнив более ранние стандарты 19-й и 24-й серий.

Чтобы понять и оценить логику, содержащуюся в семействе ГОСТ 34, проанализируем содержание составляющих его стандартов более подробно. Ориентированные на ИТ-специалистов ГОСТ 34.320-96 «Концепции и терминология для концептуальной схемы и информационной базы», ГОСТ 34.321-96. «Эталонная модель управления данными», ГОСТ 34.10 -01 «Криптографическая защита информации . Процессы формирования и проверки электронной цифровой подписи» и ГОСТ 34.11-94 «Криптографическая защита информации . Функция хэширования» я рассматривать не буду, поскольку они рассчитаны не на управленцев, а на технических специалистов. Для нас интерес представляют следующие стандарты:

  • ГОСТ 34.201-89. «Виды, комплектность и обозначение документов при создании автоматизированных систем»;
  • ГОСТ 34.003-90 «Термины и определения»;
  • ГОСТ 34.602-89 «Техническое задание на создание автоматизированной системы»;
  • ГОСТ 34.603-92 «Виды испытаний автоматизированных систем»;
  • ГОСТ 34.601-90 «Автоматизированные системы. Стадии создания»;
  • Руководящий документ РД 50-34.698-90 «Автоматизированные системы. Требования к содержанию документов».

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

Стандарт ГОСТ 34.201-89

Серьезно устаревший, но отчасти пригодный для использования стандарт (ГОСТ 34, 1989а). Устанавливает соответствие документов стадиям создания АС 1 АС — автоматизированная система, т. е. информационная система, разрабатываемая или внедряемая на конкретном предприятии. , описанным в ГОСТ 24.601 (впоследствии заменен на ГОСТ 34.601). По составу документов и стадиям проекта можно проследить происхождение стандарта из практики строительства. Очевидно, проектная природа строительства и деятельности по созданию информационной системы навела авторов стандарта на мысль распространить основные формы организации строительных проектов на проекты создания информационных систем. Отчасти это оказалось удобно — такие документы, упомянутые в стандарте, как » Техническое задание «, » Эскизный проект «, » Технический проект «, » Инструкция » (пользователя), » Программа и методика испытаний» прочно вошли в практику создания систем. С другой стороны, «Ведомость машинных носителей информации», «Каталог базы данных » или «Ведомость держателей подлинников» вряд ли сейчас имеют смысл. Стандарт включает также элементы практики делопроизводства в виде правил кодирования документов.

Короче говоря, при «творческом» подходе он может еще послужить, особенно в тех организациях, где проектная деятельность регулируется аналогичными проектно-ориентированными стандартами, а состав проектных документов близок к тому, что предлагает ГОСТ 34.201-89.

Стандарт ГОСТ 34.601-90

Один из наиболее применяемых до сих пор стандартов (ГОСТ 34, 1990), определяющий стадии и этапы создания автоматизированной системы. Приведенная ниже таблица является центральной в стандарте.

Таблица 2.1. Стадии и этапы создания автоматизированной системы по ГОСТ 34.601-90

Стадии Этапы
1. Формирование требований к АС 1.1. Обследование объекта и обоснование необходимости создания АС
1.2. Формирование требований пользователя к АС
1.3. Оформление отчета о выполненной работе и заявки на разработку АС (тактико-технического задания)
2. Разработка концепции АС 2.1. Изучение объекта
2.2. Проведение необходимых научно-исследовательских работ
2.3. Разработка вариантов концепции АС, удовлетворяющего требованиям пользователя
2.4. Оформление отчета о выполненной работе
3. Техническое задание 3.1 Разработка и утверждение технического задания на создание АС
4. Эскизный проект 4.1. Разработка предварительных проектных решений по системе и ее частям
4.2. Разработка документации на АС и ее части
5. Технический проект 5.1. Разработка проектных решений по системе и ее частям
5.2. Разработка документации на АС и ее части
5.3. Разработка и оформление документации на поставку изделий для комплектования АС и (или) технических требований (технических заданий) на их разработку
5.4. Разработка заданий на проектирование в смежных частях проекта объекта автоматизации
6. Рабочая документация 6.1. Разработка рабочей документации на систему и ее части
6.2. Разработка или адаптация программ
7. Ввод в действие 7.1. Подготовка объекта автоматизации к вводу АС в действие
7.2. Подготовка персонала
7.3. Комплектация АС поставляемыми изделиями (программными и техническими средствами, программно-техническими комплексами, информационными изделиями)
7.4. Строительно-монтажные работы
7.5. Пусконаладочные работы
7.6. Проведение предварительных испытаний
7.7. Проведение опытной эксплуатации
7.8. Проведение приемочных испытаний
8. Сопровождение АС 8.1. Выполнение работ в соответствии с гарантийными обязательствами
8.2. Послегарантийное обслуживание

Практически все перечисленные стадии и этапы до сих пор встречаются в практике создания информационных систем предприятий и организаций. Конечно, можно критиковать стандарт за негибкость в части последовательности и названий стадий и этапов, но факт остается фактом — он продемонстрировал исключительную живучесть, и понять, в чем причина этого, гораздо важнее, чем заниматься критикой разработки почти 20-летней давности. Мне кажется, что стандарт демонстрирует точное соответствие своим целям. Во-первых, он не требует знаний в области ИТ и, следовательно, понятен обычным управленцам. Во-вторых, он компактен и прост по структуре, что позволяет человеку, не знакомому с ним, быстро войти в курс дела. В-третьих, он самодостаточен — практически никаких ссылок на смежные документы в нем нет (за исключением ГОСТ 34.201). И наконец, он практичен — сразу понятно, как его применять и как контролировать его применение.

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

Стандарт ГОСТ 34.602-89

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

  1. Общие сведения.
  2. Назначение и цели создания (развития) системы.
  3. Характеристика объектов автоматизации.
  4. Требования к системе.
  5. Состав и содержание работ по созданию системы.
  6. Порядок контроля и приемки системы.
  7. Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие.
  8. Требования к документированию.
  9. Источники разработки.

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

«2.6.2. В подразделе «Требования к функциям (задачам)», выполняемым системой, приводят:

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

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

Приведенный отрывок демонстрирует иерархичность стандарта: система состоит из подсистем, комплексов задач, отдельных задач, функций. Чем точнее и подробнее сформулированы требования, тем более предсказуемым будет результат. Специально формулируются требования к функциям взаимодействия подсистем (сейчас мы бы сказали «к методам интеграции»), функции привязываются к плану-графику реализации системы (который тем самым также становится иерархическим). Специально упомянуты требования к качеству. Форма представления выходной информации , т.е. совокупность отчетов, также заслужила отдельного упоминания. Одним словом, представленный отрывок показывает, что разработка Технического задания в соответствии с ГОСТ 34.602-89 — непростая и очень трудоемкая работа, накладывающая серьезные обязательства не только на разработчика, но и на заказчика системы. Потенциал стандарта чрезвычайно велик, и неудивительно, что популярность его остается неизменно высокой на протяжении стольких лет.

Читайте также:  Гост 11293 89 марка п 11

С течением времени стали видны и оборотные стороны стандарта:

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

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

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

Источник



АСУ ТП — Автоматизированные системы управления
технологическими процессами в соответствии с ГОСТ 34.601-90

Без применения автоматизации технологических процессов в современном обществе не обходится ни одна отрасль производства. Наибольшее распространение получило внедрение и проектирование АСУ ТП в нефтяной и газовой промышленности, но в последнее время АСУ ТП затрагивает такие сферы как ЖКХ, энергетика, металлургия и многие другие.

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

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

Основные функции АСУ ТП:

Основными функциями автоматизированных систем управления технологическими процессами являются:

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

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

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

Рекомендуемая последовательность стадий по созданию АСУ ТП:

В соответствии с ГОСТ 34.601-90 рекомендуется следующая последовательность стадий по созданию АСУ ТП:

  • Формирование требований к АСУ ТП
  • Разработка концепции АСУ ТП
  • Техническое задание
  • Эскизный проект
  • Технический проект
  • Рабочий проект (Рабочая документация)
  • Ввод в действие
  • Сопровождение АСУ ТП.

Каждая из указанных стадий распределяется по этапам выполняемых работ. Рассмотрим только основные стадии создания АСУ ТП.

Разработка концепции АСУ ТП

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

Проектирование АСУ ТП

Проектирование АСУ ТП осуществляется в соответствии с Постановлением Правительства РФ от 16.02.2008 г. №87 «О составе разделов проектной документации и требованиями к их содержанию», региональными строительными нормами и требованиями технического задания. При проектировании АСУ ТП учитываются требования существующего законодательства и нормативных документов по экологии, охране труда и пожарной безопасности.

Техническое задание АСУ ТП

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

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

Технический проект АСУ ТП (стадия «ПД»)

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

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

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

Рабочая документация АСУ ТП (стадия «РД»)

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

РД разрабатывается после утверждения предшествующей стадии проектирования. Цель работ на стадии «РД» состоит в подготовке точных чертежей, схем и таблиц, которыми будут руководствоваться монтажники при проведении работ по созданию АСУ ТП. Рабочая документация обеспечивает детальную привязку компонентов всех систем к объекту. РД содержит чертежи, таблицы соединений и подключений, планы расположения оборудования и проводок и другие документы.

Цели и выгоды от создания АСУ ТП

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

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

Для определения стоимости разработки технических заданий на создание АСУ ТП и документации по общесистемным решениям, организационному, информационному, техническому, математическому и программному обеспечению АСУ ТП ЗАО «Научно-производственный центр «ВНИПИ САУ-40» и ТП «ЦЕНТРИНВЕСТпроект» был разработан «Справочник базовых цен на разработку технической документации на автоматизированные системы управления технологическими процессами (АСУ ТП)», который утвержден Министерством промышленности Российской Федерации 14 марта 1997 г. по представлению Министерства строительства Российской Федерации (письмо от 27.01.97 г. № 9-4/8).

Источник

Удобная памятка и 8 ссылок на документацию по ГОСТ 34 (автоматизированные системы)

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

Читайте также:  Гост катушки для ниток

gost_1.png

Так выглядит памятка и вот ссылка для скачивания, распечатки и вывешивания на почетное место.

gost_2.jpg

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

Расскажите, насколько часто вам приходится иметь дело с ГОСТами этой серии и насколько удается применять эти рекомендации в процессе составления документации. А ниже — небольшой опрос. Заранее большое спасибо за обратную связь!

Автор статьи: Антон Касимов, архитектор систем управления, компания «Инфосистемы Джет».

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

В каких случаях вы оформляете проектную документацию на автоматизированную систему в соответствии с ГОСТ?

  • Скопировать ссылку
  • Facebook
  • Twitter
  • ВКонтакте
  • Telegram
  • Pocket

Похожие публикации

«Инфосистемы Джет» проведет вебинар о практике защиты сред Microsoft 365

«Инфосистемы Джет» проведет вебинар для металлургов по машинному обучению

Искусственный интеллект для анализа изображений и видео. Вебинар от «Инфосистемы Джет»

Вакансии компании Инфосистемы Джет

Комментарии 23

>Старый разработчик ушёл, пришёл новый, ему дали папку с доками, он всё прочитал и врубился в продукт.
Категорически не согласен. Если бы разработка реальных продуктов шла по гостам никто бы вообще ни во что не врубался. Гост это сугубо формальный подход т.е. когда пишут не то что нужно, а то что требует Гост.

За примерами ходить далеко не надо — откройте любой большой проект на github который развивается 5-7 лет и посмотрите как там разработка устроена и документирование.

Смысл Гостов в чем? Все проекты с которыми я работал великолепно документированы прямо в коде и по этому коду сгенерирована документация с развернутыми примерами. Это позволяет сделать поменяв к примеру функцию или ее параметры получить в один клик новую актуальную версию документации.

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

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

Вопрос к тем, кому приходилось писать такую проектную документацию. Какое ПО вы использовали?

Word, на мой взгляд, не очень хорошо работает с объемными колонтитулами (а рамка обычно в них).
А так, сам пишу в Word’е.
Знаю, что некоторые люди используют (La)TeX для этого. Там есть специальные библиотеки для ЕСКД.
В Компас’е есть опция "Текстовый документ", но в той версии с которой я работал функционал был крайне скуден.

Я оформляю документацию на автоматизированную систему с использованием markup’а в простых случаях. Если документация сложная и требует интеграции с кодом, то я использую Sphinx.

Если речь идёт про API, то swagger — отличное средство для самодокументирования приложения.

Последняя линяя «документной защиты» — это debian/changelog и git log.

А зачем мне ГОСТ? Какая от него польза заказчику? Исполнителю?

Сходу поразило: «Одним пятничным вечером… получил задание от руководителя подготовить за выходные ТЗ«. Да пусть меня побьют работодатели, но с годами (к сожалению, поздно) понял, что это, за редким исключением:
а) профнепригодность руководителя (а это мы видим уже итог — неуважение к сотруднику);
б) неуважение сотрудника к самому себе (что перерастает в профнепригодность сотрудника).
Не, ну если садо встретилось с мазо — флаг в руки.

По сути. То или иное применение ГОСТов зависит от цели документации.
Если это обязаловка, то тут задача ПМ и техписа очень-очень грамотно подойти к формулированию структуры будущей документации до заключения договора/ТЗ и далее жёстко контролировать соответствие требований всех заинтересованных сторон к документации согласно вот тем самым сформулированным договорённостям, которые эти заинтересованные стороны подписали. Иначе полноценная, нормальная работа выльется в кошмар для всех сторон.
Если «для дома, для семьи», то в голове должна быть элементарная цель — документация должна быть такой, чтобы спец вашего уровня (а желательно, ступенькой ниже) понял её, точнее, описываемую систему. Тут ГОСТы должны служит опорой. Причина проста — в них аккумулирована общепринятая логика, которая с вероятностью 99.(9)% будет лучше вашей наколеночной.
Конечно, есть проблемы, тут в комментах уже обозначили. ГОСТ — это не 100% догма. Надо понять суть (логику) стандартов, в т.ч. их рамки. Это, да, требует времени и работу мысли :), а ещё и памяти (если плотно не применять, у меня быстро улетучивается, поэтому всегда работаю с постоянным обращениям к стандартам). Далее, надо сопоставить цель документации со стандартами, выработать оптимальную структуру и согласовать (см. выше). Всё, готово, можно наполнять содержанием и контролировать (через ПМ, инженеров etc) как идёт проект.

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

Источник

ГОСТ 34.601-90

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

Стандарт устанавливает стадии и этапы создания АС. В приложении 1 приведено содержание работ на каждом этапе.

1. ОБЩИЕ ПОЛОЖЕНИЯ

1.1. Процесс создания АС представляет собой совокупность упорядоченных во времени, взаимосвязанных, объединённых в стадии и этапы работ, выполнение которых необходимо и достаточно для создания АС, соответствующей заданным требованиям.

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

1.3. Работы по развитию АС осуществляют по стадиям и этапам, применяемым для создания АС.

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

Перечень организаций, участвующих в работах по созданию АС, приведён в приложении 2.

2. СТАДИИ И ЭТАПЫ СОЗДАНИЯ АС

2.1. Стадии и этапы создания АС в общем случае приведены в таблице.

1. Формирование требований к АС

1.1. Обследование объекта и обоснование необходимости создания АС.

1.2. Формирование требований пользователя к АС.

1.3. Оформление отчёта о выполненной работе и заявки на разработку АС (тактико-технического задания)

2. Разработка концепции АС.

2.1. Изучение объекта.

2.2. Проведение необходимых научно-исследовательских работ.

2.3. Разработка вариантов концепции АС, удовлетворяющего требованиям пользователя.

2.4. Оформление отчёта о выполненной работе.

3. Техническое задание.

Разработка и утверждение технического задания на создание АС.

4. Эскизный проект.

4.1. Разработка предварительных проектных решений по системе и её частям.

4.2. Разработка документации на АС и её части.

5. Технический проект.

5.1. Разработка проектных решений по системе и её частям.

5.2. Разработка документации на АС и её части.

5.3. Разработка и оформление документации на поставку изделий для комплектования АС и (или) технических требований (технических заданий) на их разработку.

5.4. Разработка заданий на проектирование в смежных частях проекта объекта автоматизации.

6. Рабочая документация.

6.1. Разработка рабочей документации на систему и её части.

6.2. Разработка или адаптация программ.

7. Ввод в действие.

7.1. Подготовка объекта автоматизации к вводу АС в действие.

7.2. Подготовка персонала.

7.3. Комплектация АС поставляемыми изделиями (программными и техническими средствами, программно-техническими комплексами, информационными изделиями).

7.4. Строительно-монтажные работы.

7.5. Пусконаладочные работы.

7.6. Проведение предварительных испытаний.

7.7. Проведение опытной эксплуатации.

7.8. Проведение приёмочных испытаний.

8. Сопровождение АС

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

8.2. Послегарантийное обслуживание.

2.2. Стадии этапы, выполняемые организациями — участниками работ по созданию АС, устанавливаются в договорах и техническом задании на основе настоящего стандарта.

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

ПРИЛОЖЕНИЕ 1
(справочное)

СОДЕРЖАНИЕ РАБОТ


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

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

3. На этапе 1.3. «Оформление отчёта о выполненной работе и заявки на разработку АС (технико-технического задания)» проводят оформление отчета о выполненных работах на данной стадии и оформление заявки на разработку АС (тактико-технического задания) или другого заменяющего её документа с аналогичным содержанием.

4. На этапах 2.1. «Изучение объекта» и 2.2. «Проведение научно-исследовательских работ» организация-разработчик проводит детальное изучение объекта автоматизации и необходимые научно-исследовательские работы (НИР), связанные с поиском путей и оценкой возможности реализации требований пользователя, оформляют и утверждают отчёты о НИР.

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

6. На этапе 2.4. «Оформление отчёта о выполненной работе» подготавливают и оформляют отчет, содержащий описание выполненных работ на стадии описания и обоснования предлагаемого варианта концепции системы.

7. На этапе 3.1. «Разработка и утверждение технического задания на создание АС» проводят разработку, оформление, согласование и утверждение технического задания на АС и, при необходимости, технических заданий на части АС.

8. На этапе 4.1. «Разработка предварительных проектных решений по системе и её частям» определяются: функции АС; функции подсистем, их цели и эффекты; состав комплексов задач и отдельных задач; концепция информационной базы, её укрупнённая структура; функции системы управления базой данных; состав вычислительной системы; функции и параметры основных программных средств.

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

10. На этапах 4.2. и 5.2. «Разработка документации на АС и её части» проводят разработку, оформление, согласование и утверждение документации в объёме, необходимом для описания полной совокупности принятых проектных решений и достаточном для дальнейшего выполнения работ по созданию АС. Виды документов — по ГОСТ 34.201-89.

11. На этапе 5.3. «Разработка и оформление документации на поставку изделий для комплектования АС и (или) технических требований (технических заданий) на их разработку» проводят: подготовку и оформление документации на поставку изделий для комплектования АС; определение технических требований и составление ТЗ на разработку изделий, не изготовляемых серийно.

12. На этапе 5.4 «Разработка заданий на проектирование в смежных частях проекта объекта автоматизации» осуществляют разработку, оформление, согласование и утверждение заданий на проектирование в смежных частях проекта объекта автоматизации для проведения строительных, электротехнических, санитарно-технических и других подготовительных работ, связанных с созданием АС.

13. На этапе 6.1 «Разработка рабочей документации на систему и её части» осуществляют разработку рабочей документации, содержащей все необходимые и достаточные сведения для обеспечения выполнения работ по вводу АС в действие и её эксплуатации, а также для поддержания уровня эксплуатационных характеристик (качества) системы в соответствии с принятыми проектными решениями, её оформление, согласование и утверждение. Виды документов по ГОСТ 34.201-89.

14. На этапе 6.2 «Разработка или адаптация программ» проводят разработку программ и программных средств системы, выбор, адаптацию и (или) привязку приобретаемых программных средств, разработку программной документации в соответствии с ГОСТ 19.101.

  • реализацию проектных решений по организационной структуре АС;
  • обеспечение подразделений объекта управления инструктивно-методическими материалами;
  • внедрение классификаторов информации.

16. На этапе 7.2 «Подготовка персонала» проводят обучение персонала и проверку его способности обеспечить функционирование АС.

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

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

  • автономную наладку технических и программных средств,
  • загрузку информации в базу данных и проверку системы её ведения;
  • комплексную наладку всех средств системы.

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

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

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

23. На этапе 8.1 «Выполнение работ в соответствии с гарантийными обязательствами» осуществляются работы по устранению недостатков, выявленных при эксплуатации АС в течении установленных гарантийных сроков, внесению необходимых изменений в документацию по АС.

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

ПРИЛОЖЕНИЕ 2
(справочное)

ПЕРЕЧЕНЬ ОРГАНИЗАЦИЙ, УЧАСТВУЮЩИХ В РАБОТАХ ПО СОЗДАНИЮ АС.

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

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

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

4. Организация-генпроектировщик объекта автоматизации.

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

Источник

Adblock
detector