Стадии и этапы создания ас кратко

Обновлено: 02.07.2024

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

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

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

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

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

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

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

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

Минусы стандартов

Основной минус всем очевиден — стандарты старые. В них заложено устаревшее представление об архитектуре автоматизированной системы. Например:

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

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

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

Стадии создания АСУ

Стадии создания определены в ГОСТ 34.601-90. Имеют отношение к документированию из них три:

  • Эскизный проект (ЭП)
  • Технический проект (ТП)
  • Разработка рабочей документации (РД)

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

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

Части (разделы) проектной документации по созданию АСУ

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

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

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

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

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

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

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

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

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

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

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

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

Заключение

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

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

Аннотация: Рассматривается один из самых распространенных в нашей стране стандартов в области ИТ — ГОСТ 34. Анализируются отдельные стандарты, входящие в ГОСТ 34.

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

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

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

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

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

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

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

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

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

Практически все перечисленные стадии и этапы до сих пор встречаются в практике создания информационных систем предприятий и организаций. Конечно, можно критиковать стандарт за негибкость в части последовательности и названий стадий и этапов, но факт остается фактом - он продемонстрировал исключительную живучесть, и понять, в чем причина этого, гораздо важнее, чем заниматься критикой разработки почти 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 - непростая и очень трудоемкая работа, накладывающая серьезные обязательства не только на разработчика, но и на заказчика системы. Потенциал стандарта чрезвычайно велик, и неудивительно, что популярность его остается неизменно высокой на протяжении стольких лет.

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

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

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

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

I этап — предпроектный (обследование, составление отчета, технико-экономического обоснования и технического задания);
II этап — проектный (составление технического и рабочего проектов);
III этап — внедрение (подготовка к внедрению, проведение опытных испытаний и сдача в программную эксплуатацию);
IV этап — анализ функционирования (выявление проблем, внесение изменений в проектные решения и существующие АИС и АИТ).

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

К методам изучения и анализа состояния экономического объекта и его системы управления относятся:

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

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

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

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

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

В процессе постановки задачи раскрываются:

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

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

Текст ГОСТ Р 59793-2021 Информационные технологии. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Стадии создания

ФЕДЕРАЛЬНОЕ АГЕНТСТВО ПО ТЕХНИЧЕСКОМУ РЕГУЛИРОВАНИЮ И МЕТРОЛОГИИ


НАЦИОНАЛЬНЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ

КОМПЛЕКС СТАНДАРТОВ НА АВТОМАТИЗИРОВАННЫЕ СИСТЕМЫ

Москва Российский институт стандартизации 2021

Предисловие

3 УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Приказом Федерального агентства по техническому регулированию и метрологии от 25 октября 2021 г. № 1285-ст

4 ВВЕДЕН ВПЕРВЫЕ

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

ГОСТ Р 59793—2021

НАЦИОНАЛЬНЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ

КОМПЛЕКС СТАНДАРТОВ НА АВТОМАТИЗИРОВАННЫЕ СИСТЕМЫ

Автоматизированные системы. Стадии создания

Information technology. Set of standards for automated systems. Stages of development

Дата введения — 2022—04—30

1 Область применения

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

Стандарт устанавливает стадии и этапы создания АС.

8 приложении А приведено содержание работ на каждом этапе.

2 Нормативные ссылки

В настоящем стандарте использованы нормативные ссылки на следующие стандарты:

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

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

3 Общие положения

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

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

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

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

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

4 Состав и содержание

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

Таблица 1—Стадии и этапы создания АС

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

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

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

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

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

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

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

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

2.4 Оценка рисков проекта

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

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 Послегарантийное обслуживание

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

Допускается исключать отдельные этапы работ на всех стадиях.

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

Приложение А (справочное)

Содержание работ

- сбор данных об объекте автоматизации и осуществляемых видах деятельности;

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

• оценку (технико-экономической, социальной и т. п.) целесообразности создания АС.

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

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

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

• устранение неисправностей и внесение изменений в документацию на АС. в том числе эксплуатационную в соответствии с протоколом испытаний:

• оформление акта о приемке АС в опытную эксплуатацию.

• опытную эксплуатацию АС;

• анализ результатов опытной эксплуатации АС:

• доработку (при необходимости) программного и информационного обеспечения АС;

• доработку (при необходимости) документации на АС;

• дополнительную наладку (при необходимости) технических средств АС;

• оформление акта о завершении опытной эксплуатации.

• испытания на соответствие техническому заданию на создание АС в соответствии с программой и методикой приемочных испытаний;

• анализ результатов испытаний АС и устранение недостатков, выявленных при испытаниях;

• оформление акта о приемке АС в постоянную эксплуатацию.

• по анализу функционирования АС:

• по выявлению отклонений фактических эксплуатационных характеристик АС от проектных значений;

• по установлению причин этих отклонений;

• по устранению выявленных недостатков и обеспечению стабильности эксплуатационных характеристик АС;

• по внесению необходимых изменений в документацию на АС.

Приложение Б (справочное)

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

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

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

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

Б.4 Генлроектировщик объекта автоматизации.

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

Б.6 Организации строительные, монтажные, наладочные и другие.

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

2 Стадии и этапы выполняемых ими работ по созданию АС определяются на основании настоящего стандарта.

ОКС 35.240:01.040.35

Ключевые слова: информационные технологии, автоматизированные системы, стадии создания

Редактор Л.В. Каретникова Технический редактор В.Н. Прусакова Корректор Р.А. Ментова Компьютерная верстка П.А. Круговой

Сдано е набор 28.10.202! Подписано е печать 1B.il.2021. Формат 60’844. Гарнитура Ариал.

Усп. печ. л. 0.93. Уч.-изд. л. 0.88.

Подготовлено на основе электронной версии. предоставленной разработчиком стандарта

117418 Москва. Нахимовский пр-т. д. 3t. х. 2

Превью ГОСТ Р 59793-2021 Информационные технологии. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Стадии создания

Читайте также: