В последний год одним из самых обсуждаемых вопросов на многих IT-мероприятиях, включая InfoSecurity Russia 2014, РИФ+КИБ 2015 и Связь-Экспокомм-2015, стал закон об импортозамещении ПО, призванный ограничить долю импортного программного обеспечения к 2025 году размером не более 50%. Законом живо интересуются не только сами производители отечественного софта, но и другие участники рынка: потребители, эксперты отрасли и государство.

Добавляет оптимизма то, что в некоторых сегментах ИТ-продуктов мы имеем уже готовые к конкуренции решения. До 1 июля, когда закон вступит в действие, осталось недолго. Давайте посмотрим, с какими аргументами о целесообразности замены зарубежного ПО подходят к этой дате отечественные компании, такие как ALT Linux, «Смарт-Софт» и TrueConf, давно популяризующие принцип альтернативы продуктам западных корпораций-монстров.

Была ли жизнь на Марсе? Импортозамещение до принятия госпрограммы

Качественное использование законотворческих инициатив правительства хорошо видно на примере компании «ALT Linux ».

Благодаря жестким требованиям «Закона о персональных данных », последующим актам и изменившимся условиям тендерных закупок в 2012-2013 годах компания поставила свои программные продукты на 45 000 рабочих мест.

Сейчас «ALT Linux» участвует в консорциумах по трём направлениям закона об импортозамещении: мобильные и десктопные ОС, серверные ОС и СУБД. Причем старается опираться как на свои разработки, так и интегрировать в процесс небольшие компании-разработчики и ВУЗы .

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

Отечественные компании против западных монстров разработки

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

К примеру, убеждая потенциальных заказчиков перейти на наш продукт «Traffic Inspector», ничем не уступающий западным аналогам, мы используем следующие аргументы:

1. Цена. TI выгоднее как по стоимости приобретения, так и по стоимости продления. Для примера сравним с Kerio, с которого достаточно часто, в том числе из-за более полных отчетов, переходят на «Traffic Inspector» . Kerio на 5 пользователей стоит 282 евро (больше 16000 р. по текущему курсу), а «Traffic Inspector» - 4900 р. Продление же лицензий обходится примерно в 5170 р. у Kerio (приблизительно 1/3 от первоначальной стоимости продукта) против 1470 р. у TI, и дальнейшие оплаты лицензий не привязаны к валютному курсу, что крайне выгодно и понятно корпоративному и государственному заказчику.
2. Безопасность. Закрытие иностранного ПО для использования в России (отказ в продлении, запрет на продажу и т.д.) - вполне объективная угроза работе любого предприятия. Плюс абсолютно ненулевая вероятность наличия программных закладок, что чревато утечкой критической информации.

Отдельным аргументом выступает качество технической поддержки и скорости реагирования на проблемы пользователей. Если раньше нашим разработчикам нечего было ответить на аргумент клиента: «Мы возьмём оборудование и ПО у известного мирового бренда, они обеспечат мировой уровень техподдержки », - то сейчас времена изменились. Именно отсутствие качественной и своевременной поддержки от CISCO в решении проблем явилось одним из главных аргументов перехода всей системы видеонаблюдения Москвы на отечественный софт. Это, не считая прямого отказа продажи оборудования. А бюджет развития IT-инфраструктуры по Москве - 5-7 миллиардов рублей ежегодно.

Как зарабатывать на отечественном софте. Позиция TrueConf

Работая на внедрении российского ПО на рынке видеоконференцсвязи, TrueConf показывает не только хорошую динамику реализованных проектов (свыше 25 тысяч рабочих мест и переговорных комнат), но и хорошо продуманную стратегию развития:

1. Присутствие иностранных конкурентов компания рассматривает как стимул к развитию.
2. Основа компании - сильная школа отечественных программистов.
3. Основная стратегическая цель - выход на мировые рынки.

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

Общие черты и различия в подходах компаний

Безусловно, все хотят делить пирог господдержки по-своему. Но есть общая черта у всех серьезных практиков импортозамещения: они готовы делиться со всеми активными участниками процесса. Если программисты свободного софта предпочитают видеть соавторами систему образования и ВУЗы, то коммерческие разработчики отдают пальму первенства партнёрам и внедренцам на местах.

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

Положительный опыт импортозамещения и перспективы

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

Так, многие госучреждения и крупные корпорации стараются склоняться к покупке отечественного конкурентоспособного ПО. Так, например, переход давно наметился в федеральных и региональных органах (Центральный банк РФ, Министерство юстиции, Государственная Дума Федерального Собрания Российской Федерации, Мэрия Москвы и др.), банках (ВТБ 24, Московский индустриальный банк, Сбербанк, Коммерческий банк «Петрокоммерц» и др.), промышленности (ФГУП «Центр эксплуатации объектов наземной космической инфраструктуры», «АТЛАНТ»), ТЭК («ЭНЕРГОАТОМ», «Нижнекамскнефтехим»), строительстве («Газфлот», Группа компаний «МонАрх») и других областях.

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

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

О необходимости форсированного развития отечественного рынка ПО, обеспечения максимальной независимости от иностранных разработок в сфере высоких технологий и сохранения информационного суверенитета впервые на высшем уровне заговорили в 2014 году, когда санкции США и Евросоюза резко повысили риски, связанные с применением зарубежного софта в бизнесе и государственных организациях. Именно тогда в Министерстве связи и массовых коммуникаций РФ всерьёз озадачились решением этого стратегически значимого, по мнению чиновников, вопроса вместе со стимулированием спроса на национальные продукты и проработкой соответствующих мер поддержки отечественных разработчиков. Как результат — в кратчайшие сроки на законодательном уровне были утверждены ограничения на допуск иностранного ПО при осуществлении государственных и муниципальных закупок, а также правила формирования и ведения единого реестра российских программ. Всё это положительным образом отразилось на рынке программного обеспечения в России, который за последнее время пополнился множеством интересных проектов и разработок. В том числе и в области операционных систем.

«Альт Линукс СПТ» представляет собой унифицированный дистрибутив на базе Linux для серверов, рабочих станций и тонких клиентов со встроенными программными средствами защиты информации, который может быть использован для построения автоматизированных систем по класс 1В включительно и информационных систем персональных данных (ИСПДн) по класс 1К включительно. ОС позволяет одновременно хранить и обрабатывать на одном персональном компьютере или сервере конфиденциальные данные, обеспечивать многопользовательскую работу с разграничением доступа к информации, работать с виртуальными машинами, а также использовать средства централизованной авторизации. Выданный ФСТЭК России сертификат подтверждает соответствие продукта требованиям следующих руководящих документов: «Средства вычислительной техники. Защита от несанкционированного доступа к информации. Показатели защищённости от несанкционированного доступа к информации» — по 4 классу защищённости; «Защита от несанкционированного доступа к информации. Часть 1. Программное обеспечение средств защиты информации. Классификация по уровню отсутствия недекларированных возможностей» — по 3-му уровню контроля и технических условий. Техническая поддержка пользователей «Альт Линукс СПТ » осуществляется компанией «Свободные программы и технологии» через партнёра-разработчика «Базальт СПО».

⇡

Разработчик: компания «Базальт СПО»

Платформа «Альт» — это набор Linux-дистрибутивов уровня предприятия, позволяющих развернуть корпоративную IT-инфраструктуру любого масштаба. В состав платформы входят три дистрибутива. Это универсальный «Альт Рабочая станция», включающий в себя операционную систему и набор приложений для полноценной работы. Второй — серверный дистрибутив «Альт Сервер», который может выступать контроллером домена Active Directory и содержит максимально полный набор служб и сред для создания корпоративной инфраструктуры (СУБД, почтовый и веб-сервер, средства аутентификации, группой работы, управления виртуальными машинами и мониторинга и прочие инструменты). Третий — «Альт Образование 8», ориентированный на повседневное использование при планировании, организации и проведении учебного процесса в учреждениях общего, среднего и высшего образования. Помимо этого, в серии продуктов компании «Базальт СПО» представлены упомянутый выше сертифицированный дистрибутив «Альт Линукс СПТ» и операционная система для домашних пользователей Simply Linux.

⇡

Разработчик: Национальный центр информатизации (входит в госкорпорацию «Ростех»)

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

Разработка научно-производственного объединения «РусБИТех», представленная в двух вариантах: Astra Linux Common Edition (общего назначения) и Astra Linux Special Edition (специального назначения). Особенности последней версии ОС: развитые средства обеспечения информационной безопасности обрабатываемых данных, механизм мандатного разграничения доступа и контроля замкнутости программной среды, встроенные инструменты маркировки документов, регистрации событий, контроля целостности данных, а также прочие обеспечивающие защиту информации компоненты. По заверениям разработчиков, Astra Linux Special Edition — единственная программная платформа, сертифицированная одновременно в системах сертификации средств защиты информации ФСТЭК России, ФСБ, Минобороны РФ и позволяющая обрабатывать в автоматизированных средствах всех министерств, ведомств и других учреждений Российской Федерации информацию ограниченного доступа, содержащую составляющие государственную тайну сведения с грифом не выше «совершенно секретно».

⇡ ROSA Linux

Разработчик: ООО «НТЦ ИТ РОСА»

Семейство операционных систем ROSA Linux включает внушительный набор решений, предназначенных для домашнего использования (версия ROSA Fresh) и применения в корпоративной среде (ROSA Enterprise Desktop), развёртывания инфраструктурных IT-служб организации (ROSA Enterprise Linux Server), обработки конфиденциальной информации и персональных данных (РОСА «Кобальт»), а также составляющих государственную тайну сведений (РОСА «Хром» и «Никель»). В основу перечисленных продуктов положены наработки Red Hat Enterprise Linux, Mandriva и CentOS с включением большого количества дополнительных компонентов — в том числе оригинальных, созданных программистами научно-технического центра информационных технологий «РОСА». В частности, в составе дистрибутивов ОС для корпоративного сегмента рынка представлены средства виртуализации, ПО для организации резервного копирования, инструменты для построения частных облаков, а также централизованного управления сетевыми ресурсами и системами хранения данных.

⇡

Разработчик: компания «Калкулэйт»

Calculate Linux представлен в редакциях Desktop, Directory Server, Scratch, Scratch Server и создан с прицелом на домашних пользователей и организации малого и среднего бизнеса, предпочитающие использовать ПО с открытым исходным кодом вместо проприетарных решений. Особенности платформы: полноценная работа в гетерогенных сетях, механизм перемещаемых профилей пользователей, инструментарий централизованного развёртывания программного обеспечения, простота администрирования, возможность установки на портативные USB-накопители и поддержка бинарных репозиториев обновлений Gentoo. Важно, что команда разработчиков доступна и открыта для любых замечаний, предложений и пожеланий пользовательской аудитории, о чем свидетельствует огромное количество способов принять участие в сообществе Calculate Linux и развитии платформы.

⇡ «Ульяновск. BSD»

Разработчик: Сергей Волков

Операционная система, которая построена на основе свободно распространяемой платформы FreeBSD и содержит необходимый набор прикладных программ для домашних пользователей и выполнения офисных задач. По словам единственного разработчика ОС Сергея Волкова, «Ульяновск.BSD» полностью адаптирована к потребностям именно русскоязычных пользователей. «Наша сборка максимально облегчена и идеально подходит для использования как на домашних компьютерах, так и на рабочих станциях сотрудников различных организаций, а также для использования в образовательных заведениях», — утверждает автор проекта, не вдаваясь в подробности того, чем конкретно скомпилированный им продукт отличается от оригинала. Солидности проекту добавляют не только наличие распространяемого на коммерческих условиях дистрибутива и платная техническая поддержка, но и запись в реестре российского ПО. Это означает, что программная платформа «Ульяновск.BSD» на законных основаниях может применяться государственными организациями в рамках проектов по внедрению импортозамещающих технологий.

Сертифицированная и защищённая операционная система, позволяющая обрабатывать информацию в соответствии с ФЗ № 152 «О персональных данных» и реализовывать системы обработки информации ограниченного доступа, не относящейся к государственной тайне. ICLinux включает средства удалённого администрирования, имеет встроенный межсетевой экран, сертифицированный на соответствие РД МЭ по 3-му классу защищённости, поддерживает RDP, X-Windows System, SSH, Telnet, VNC, VPN, NX, ICA и прочие протоколы. Также в активе платформы значатся совместимость со средствами аутентификации компании «Аладдин Р.Д.» и модульная архитектура, которая позволяет гибко настраивать операционную систему под требования заказчика.

⇡ «Альфа ОС» (Alfa OS)

Разработчик: компания ALFA Vision

Ещё один клон Linux, снабжённый пользовательским интерфейсом а-ля macOS с набором привычных офисных приложений и наполненный глубоким философским смыслом. Без шуток, на сайте разработчика в разделе «О компании», так и сказано: «Операционная система — это особое явление, точка, в которой сходятся технологические, эстетические и гуманитарные концепции. Вершина, которая видна со всех сторон. Чтобы она засияла, стала тем, чем должна быть, необходим самый разнообразный осмысленный опыт. И он у нас есть ». Сколько экспрессии в этих словах, какая подача информации! Согласитесь, не каждый может так выразительно преподнести свой продукт широкой аудитории. В настоящий момент «Альфа ОС» представлена в виде десктопной версии для x86-совместимых систем. В будущем компания ALFA Vision намерена выкатить на рынок мобильную и серверную редакции ОС, а также сборку дистрибутива для устройств на базе процессоров ARM.

Программная платформа, разработанная специально для вычислительных комплексов с архитектурой SPARC и «Эльбрус». Особенностью системы является кардинально переработанное ядро Linux, в котором были реализованы особые механизмы управления процессами, виртуальной памятью, прерываниями, сигналами, синхронизацией, поддержка тегированных вычислений. «Нами была проделана фундаментальная работа по преобразованию ОС Linux в операционную систему, поддерживающую режим работы в реальном времени, для чего были реализованы актуальные оптимизации в ядре. В ходе работы в реальном времени можно устанавливать различные режимы обработки внешних прерываний, планирования вычислений, обменов с дисковыми накопителями и некоторые другие », — поясняют в компании «МЦСТ». Помимо этого, в ядро программной платформы «Эльбрус» встроен комплекс средств защиты информации от несанкционированного доступа, который позволяет использовать ОС для построения автоматизированных систем, отвечающих самым высоким требованиям информационной безопасности. Также в составе системы представлены средства архивации, планирования заданий, разработки ПО и прочие инструменты.

⇡ «Ред ОС»

Операционная система на основе ядра Linux, созданная с прицелом на обеспечение безопасности обрабатываемых данных. «Ред ОС» соответствует отечественным требованиям по защите информации, имеет преднастроенные конфигурации для каждой аппаратной архитектуры, использует алгоритмы ГОСТ 34.11-2012 в протоколах ssh и NX, а также поддерживает списки управления доступом. Помимо этого, ОС поддерживает сетевую аутентификацию с помощью подключаемых модулей аутентификации (PAM, Pluggable Authentication Modules) и имеет в своём составе специализированную подсистему распределённого аудита, которая позволяет отслеживать критичные события безопасности в корпоративной сети и предоставляет IT-администратору необходимые инструменты для оперативного реагирования на инциденты ИБ.

⇡ GosLinux («ГосЛинукс»)

Разработчик: компания «Ред Софт»

ОС GosLinux создана специально для нужд Федеральной службы судебных приставов Российской Федерации (ФССП России) и пригодна для использования во всех органах власти, государственных внебюджетных фондах и органах местного самоуправления. Платформа построена на базе дистрибутива CentOS 6.4, включающего наработки Red Hat Enterprise Linux. Система представлена в двух редакциях — для серверов и рабочих станций, содержит упрощённый графический интерфейс и набор преднастроенных средств защиты информации. Разработчик ОС — компания «Ред Софт», победившая в марте 2013 года в конкурсе на доработку, внедрение и сопровождение автоматизированных информационных систем ФССП России. В 2014 году система получила сертификат соответствия ФСТЭК России, подтверждающий, что «ГосЛинукс» имеет оценочный уровень доверия ОУД3 и соответствует требованиям руководящего документа Гостехкомиссии РФ по 4-му уровню контроля отсутствия недекларированных возможностей. Дистрибутив ОС GosLinux для органов государственной власти размещён в национальном фонде алгоритмов и программ по адресу nfap.minsvyaz.ru . В настоящий момент платформа GosLinux активно развёртывается во всех территориальных органах и подразделениях ФССП России. Также ОС передана на опытную эксплуатацию представителям властей Нижегородской, Волгоградской и Ярославской областей.

⇡

Разработчик: ООО «Алми»

Сайт продукта:

Ещё одна сборка Linux в нашем списке, которая определённо не страдает от недостатка хвалебных эпитетов в свой адрес со стороны разработчиков. «Уникальная, идеальная, простая, совмещающая в себе удобство операционной системы Windows, стабильность macOS и безопасность Linux » — такими возносящими AlterOS до небес фразами вдоль и поперёк прошит официальный сайт продукта. В чём именно заключается уникальность отечественной платформы, на сайте не сказано, зато представлена информация о трёх редакциях ОС: AlterOS «Волга» для государственного сектора, AlterOS «Амур» для корпоративного сегмента и AlterOS «Дон» для серверов. Сообщается о совместимости системы со множеством востребованных в бизнес-среде программных решений, в том числе с «1С» и «Консультант Плюс», а также отечественными средствами криптозащиты (например, «КриптоПро»). Отдельный акцент сделан на отсутствии в версии платформы для госорганизаций ПО, которое взаимодействует с иностранными серверами, — всё сделано по канонам максимального импортозамещения, заявляют разработчики.

⇡ Мобильная система Вооружённых Сил (МСВС)

Разработчик: Всероссийский научно-исследовательский институт автоматизации управления в непромышленной сфере им. В. В. Соломатина (ВНИИНС)

Защищённая операционная система общего назначения, предназначенная для построения стационарных и мобильных защищённых автоматизированных систем в Вооружённых Силах Российской Федерации. Принята на снабжение в ВС РФ в 2002 году. В основу МСВС положены ядро и компоненты Linux, дополненные дискреционной, мандатной и ролевой моделями разграничения доступа к информации. Система функционирует на аппаратных платформах Intel (x86 и x86_64), SPARC («Эльбрус-90микро»), MIPS, PowerPC64, SPARC64 и сертифицирована по требованиям безопасности информации Министерства обороны РФ. Реализованные в МСВС средства защиты позволяют создавать на базе платформы автоматизированные системы, которые обрабатывают составляющие государственную тайну сведения, имеющие степень секретности «СС» (совершенно секретно).

⇡ «Заря»

Разработчик: ФГУП «Центральный научно-исследовательский институт экономики, информатики и систем управления» («ЦНИИ ЭИСУ», входит в «Объединённую приборостроительную корпорацию»)

Семейство программных платформ на ядре Linux, которые представляют собой альтернативу зарубежным ОС, применяемым сейчас в силовых ведомствах, госсекторе и на оборонных предприятиях. Настольная операционная система «Заря» совместима с большинством традиционных офисных приложений и программ. Серверная платформа «Заря-ЦОД» позволяет организовать сервер приложений или сервер базы данных. Для построения центров обработки данных она предлагает стандартный набор серверного ПО, средства виртуализации, а также возможность работы на так называемом «большом железе», включая мейнфреймы. Для встраиваемых систем, работающих без участия человека, которые должны обрабатывать информацию в режиме реального времени, разработана специальная ОС «Заря РВ». Система соответствует третьему классу защиты от несанкционированного доступа и второму уровню контроля отсутствия недекларированных возможностей. Платформа разработана по заказу Минобороны России и, как ожидается, будет востребована силовыми ведомствами, оборонным комплексом, а также коммерческими структурами, работающими с государственной тайной и персональными данными.

Операционная система для терминальных станций. Создана на базе Linux и содержит только необходимый набор инструментов для организации рабочих мест с использованием тонких клиентов. Все функции, выходящие за эти рамки, исключены из дистрибутива. Kraftway Terminal Linux поддерживает множество сетевых протоколов прикладного уровня (RDP, VNC, SSH, NX, XWindow, VMWare View PCoIP и др.), позволяет настраивать права доступа на проброс USB-носителей, обеспечивает возможность использования сетевых и локальных принтеров, содержит средства восстановления конфигурации ОС при перезагрузке, а также инструменты дистанционного группового управления терминальными станциями и администрирования рабочих мест. Особенность системы — высокая защищённость. Kraftway Terminal Linux поддерживает и аппаратные средства аутентификации пользователей: USB-ключи eToken PRO и eToken PRO Java от ЗАО «Аладдин Р.Д.», а также RuToken S и RuToken ЭЦП от ЗАО «Актив-софт». Обновление ОС может осуществляться администратором через локальную сеть или с USB-накопителя. Возможна настройка автообновления как с локального сервера заказчика, так и с сервера компании Kraftway.

⇡ WTware

Разработчик: Андрей Ковалёв

Ещё одна программная платформа для развёртывания в IT-инфраструктуре предприятия рабочих мест с использованием недорогих терминальных решений. В дистрибутив WTware включены службы для загрузки по сети, инструменты для работы с принтерами, сканерами штрихкодов и прочим периферийным оборудованием. Поддерживается перенаправление COM- и USB-портов, а также аутентификация по смарт-картам. Для подключения к серверу терминалов используется протокол RDP, а для оперативного разрешения возникающих при настройке операционной системы вопросов к дистрибутиву прилагается подробная документация. WTware распространяется на коммерческих условиях и лицензируется по количеству рабочих станций. Для мини-компьютера Raspberry Pi разработчиком предлагается бесплатная версия ОС.

⇡ KasperskyOS

Разработчик: «Лаборатория Касперского»

Безопасная операционная система, предназначенная для использования в критически важных инфраструктурах и устройствах. Платформа «Лаборатории Касперского» может быть задействована в автоматизированных системах управления технологическими процессами (АСУ ТП), телекоммуникационном оборудовании, медицинских аппаратах, автомобилях и прочих гаджетах из мира Интернета вещей. ОС создана с нуля и в силу своей архитектуры гарантирует высокий уровень информационной безопасности. Основной принцип работы KasperskyOS сводится к правилу «запрещено всё, что не разрешено». Это позволяет исключить возможность эксплуатирования как уже известных уязвимостей, так и тех, что будут обнаружены в будущем. При этом все политики безопасности, в том числе запреты на выполнение определённых процессов и действий, настраиваются в соответствии с потребностями организации. Платформа будет поставляться в качестве предустановленного программного обеспечения на различных типах оборудования, применяемого в индустриальных и корпоративных сетях. В настоящее время безопасная ОС «Лаборатории Касперского» внедрена в маршрутизирующий коммутатор уровня L3, разработанный компанией Kraftway.

Операционная система реального времени (ОСРВ), написанная программистами «АстроСофт» с нуля, без заимствований чужого кода, и предназначенная прежде всего для Интернета вещей и встроенных устройств. Кроме того, она подходит для робототехники, медицинского оборудования, систем «умного дома» и «умного города», потребительской электроники и пр. Впервые ОС реального времени «МАКС» (аббревиатура расшифровывается как «мультиагентная когерентная система») была продемонстрирована широкой аудитории в январе 2017 года. Платформа не только реализует всю классическую функциональность продуктов данного типа, но и обладает рядом уникальных возможностей по организации взаимодействия множества устройств, позволяющих упростить создание необходимых во встраиваемых системах механизмов: резервирование, горячая замена оборудования и др. Одна из особенностей «МАКС» — поддержка разделяемой памяти на уровне устройств. Данный механизм обеспечивает автоматическую, устойчивую к сбоям отдельных компонентов синхронизацию информации между узлами распределённой системы. ОСРВ «МАКС» включена в реестр отечественного программного обеспечения. Кроме этого, продукт зарегистрирован в Федеральной службе по интеллектуальной собственности (Роспатент) и в настоящее время проходит сертификацию в Федеральной службе по техническому и экспортному контролю (ФСТЭК России) по четвёртому уровню контроля недекларированных возможностей (НДВ).

⇡ В качестве заключения

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

Согласно ГОСТ 34.602-89 ТЗ должно содержать следующие разделы (приведены в сокращенном виде):

1. Общие сведения
1. полное наименование системы и ее условное обозначение;

Полное наименование системы: Автоматизированная система "Управление" Условное обозначение: АСУ

1. 1. шифр темы или шифр (номер) договора;

1. Пример:

Договор № ХХХ от ДД.ММ.ГГГГ

1. 1.наименование предприятий (объединений) разработчика и заказчика (пользователя) системы и их реквизиты;

1. Пример:

ЗАКАЗЧИК Наименование заказчика: ООО "МИР" Юридический адрес заказчика: 142345, г. Москва, ул. Тверская, дом 15 Почтовый адрес заказчика: 142345, г. Москва, ул. Тверская, дом 15 Фактический адрес заказчика: 142345, г. Москва, ул. Тверская, дом 15 Телефон: +7 903 456 67 67 Факс: +7 903 453 34 54 Адрес электронной почты: [email protected] ОГРН: 4554545445454 ИНН: 4343434345 КПП: 453345443 БАНК: ЗАО "БанкСтрой", г. Москва БИК: 444454554 РС: 564456456456454453445 КС: 43223423{{[[Шаблон:|]]}}400000000234

ИСПОЛНИТЕЛЬ Наименование исполнителя: ООО "ДЯТЕЛ" Юридический адрес заказчика: 142345, г. Москва, ул. Ленина, дом 34 Почтовый адрес заказчика: 142345, г. Москва, ул. Ленина, дом 34 Фактический адрес заказчика: 142345, г. Москва, ул. Ленина, дом 34 Телефон: +7 495 345 63 63 Факс: +7 495 433 34 54 Адрес электронной почты: [email protected] ОГРН: 4554545445454 ИНН: 4343434345 КПП: 453345443 БАНК: ЗАО "БанкСтрой", г. Москва БИК: 444454554 РС: 564456456456454453445 КС: 43223423400000000234

1 1. перечень документов, на основании которых создается система, кем и когда утверждены эти документы;

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

2. Назначение и цели создания системы

3. Характеристика объекта автоматизации

1 краткие сведения об объекте автоматизации или ссылки на документы, содержащие такую информацию;

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

4. Требования к системе

1. Требования к системе в целом;

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

3. Требования к видам обеспечения.

5. Состав и содержание работ по созданию системы

1. перечень документов по ГОСТ 34.201, предъявляемых по окончании соответствующих стадий и этапов работ;
2. вид и порядок проведения экспертизы технической документации (стадия, этап, объем проверяемой документации, организация-эксперт);
3. программа работ, направленных на обеспечение требуемого уровня надежности разрабатываемой системы (при необходимости);
4. перечень работ по метрологическому обеспечению на всех стадиях создания системы с указанием их сроков выполнения и организации-исполнителей (при необходимости).

6. Порядок контроля и приемки системы

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

7. Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие

1. приведение поступающей в систему информации (в соответствии с требованиями к информационному и лингвистическому обеспечению) к виду, пригодному для обработки с помощью ЭВМ;
2. изменения, которые необходимо осуществить в объекте автоматизации;
3. создание условий функционирования объекта автоматизации, при которых гарантируется соответствие создаваемой системы требованиям, содержащимся в ТЗ;
4. создание необходимых для функционирования системы подразделений и служб;
5. сроки и порядок комплектования штатов и обучения персонала.

8. Требования к документированию

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

9. Источники разработки: документы и информационные материалы (технико-экономическое обоснование, отчеты о законченных научно-исследовательских работах, информационные материалы на отечественные, зарубежные системы-аналоги и др.), на основании которых разрабатывалось ТЗ и которые должны быть использованы при создании системы.

Название документа:
Номер документа:	34.602-89
Вид документа:	ГОСТ
Принявший орган:	Госстандарт СССР
Статус:	Действующий
Опубликован:
Дата принятия:	24 марта 1989
Дата начала действия:	01 января 1990
Дата редакции:	01 июня 2009

ГОСТ 34.602-89 Информационная технология (ИТ). Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы

ГОСТ 34.602-89

Группа П87

МЕЖГОСУДАРСТВЕННЫЙ СТАНДАРТ

ИНФОРМАЦИОННАЯ ТЕХНОЛОГИЯ

Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы

Information technology. Set of standards for automated systems. Technical directions for automated system making

МКС 35.080
ОКСТУ 0034

Дата введения 1990-01-01

ИНФОРМАЦИОННЫЕ ДАННЫЕ

1. РАЗРАБОТАН И ВНЕСЕН Государственным комитетом СССР по стандартам, Министерством приборостроения, средств автоматизации и систем управления СССР

2. УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Постановлением Государственного комитета СССР по стандартам от 24.03.89 N 661

3. ВЗАМЕН ГОСТ 24.201-85

4. ССЫЛОЧНЫЕ НОРМАТИВНО-ТЕХНИЧЕСКИЕ ДОКУМЕНТЫ

	Номер пункта, приложения
ГОСТ 2.105-95
ГОСТ 2.301-68
ГОСТ 2.501-88	Приложение 1
ГОСТ 6.10.1-88
ГОСТ 6.10.4-84
ГОСТ 19.201-78
ГОСТ 34.201-89
ГОСТ 34.601-90

5. ПЕРЕИЗДАНИЕ. Июнь 2009 г.


Настоящий стандарт распространяется на автоматизированные системы (АС) для автоматизации различных видов деятельности (управление, проектирование, исследование и т.п.), включая их сочетания, и устанавливает состав, содержание, правила оформления документа "Техническое задание на создание (развитие или модернизацию) системы" (далее - ТЗ на АС).

Рекомендуемый порядок разработки, согласования и утверждения ТЗ на АС приведен в приложении 1.

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

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

1.1. ТЗ на АС является основным документом, определяющим требования и порядок создания (развития или модернизации - далее создания) автоматизированной системы, в соответствии с которым проводится разработка АС и ее приемка при вводе в действие.

1.2. ТЗ на АС разрабатывают на систему в целом, предназначенную для работы самостоятельно или в составе другой системы.

Дополнительно могут быть разработаны ТЗ на части АС: на подсистемы АС, комплексы задач АС и т.п. в соответствии с требованиями настоящего стандарта; на комплектующие средства технического обеспечения и программно-технические комплексы в соответствии со стандартами ЕСКД и СРПП; на программные средства в соответствии со стандартами ЕСПД; на информационные изделия в соответствии с ГОСТ 19.201 и НТД, действующей в ведомстве заказчика АС.

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

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

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

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

1.5. ТЗ на АС разрабатывают на основании исходных данных, в том числе содержащихся в итоговой документации стадии "Исследование и обоснование создания АС", установленной ГОСТ 34.601 .

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

1.7. Изменения к ТЗ на АС оформляют дополнением или подписанным заказчиком и разработчиком протоколом. Дополнение или указанный протокол являются неотъемлемой частью ТЗ на АС. На титульном листе ТЗ на АС должна быть запись "Действует с …".

2. СОСТАВ И СОДЕРЖАНИЕ

2.1. ТЗ на АС содержит следующие разделы, которые могут быть разделены на подразделы:

1) общие сведения;

2) назначение и цели создания (развития) системы;

3) характеристика объектов автоматизации;

4) требования к системе;

5) состав и содержание работ по созданию системы;

6) порядок контроля и приемки системы;

7) требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие;

8) требования к документированию;

9) источники разработки.

В ТЗ на АС могут включаться приложения.

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

В ТЗ на части системы не включают разделы, дублирующие содержание разделов ТЗ на АС в целом.

2.3. В разделе "Общие сведения" указывают:

1) полное наименование системы и ее условное обозначение;

2) шифр темы или шифр (номер) договора;

3) наименование предприятий (объединений) разработчика и заказчика (пользователя) системы и их реквизиты;

4) перечень документов, на основании которых создается система, кем и когда утверждены эти документы;

5) плановые сроки начала и окончания работы по созданию системы;

6) сведения об источниках и порядке финансирования работ;

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

2.4. Раздел "Назначение и цели создания (развития) системы" состоит из подразделов:

1) назначение системы;

2) цели создания системы.

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

Для АСУ дополнительно указывают перечень автоматизируемых органов (пунктов) управления и управляемых объектов.

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

2.5. В разделе "Характеристики объекта автоматизации" приводят:

1) краткие сведения об объекте автоматизации или ссылки на документы, содержащие такую информацию;

2) сведения об условиях эксплуатации объекта автоматизации и характеристиках окружающей среды.

Примечание. Для САПР в разделе дополнительно приводят основные параметры и характеристики объектов проектирования.

2.6. Раздел "Требования к системе" состоит из следующих подразделов:

1) требования к системе в целом;

2) требования к функциям (задачам), выполняемым системой;

3) требования к видам обеспечения.

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

2.6.1. В подразделе "Требования к системе в целом" указывают:

- требования к структуре и функционированию системы;

- требования к численности и квалификации персонала системы и режиму его работы;

- показатели назначения;

- требования к надежности;

- требования безопасности;

- требования к эргономике и технической эстетике;

- требования к транспортабельности для подвижных АС;

- требования к эксплуатации, техническому обслуживанию, ремонту и хранению компонентов системы;

- требования к защите информации от несанкционированного доступа;

- требования по сохранности информации при авариях;

- требования к защите от влияния внешних воздействий;

- требования к патентной чистоте;

Требования по стандартизации и унификации;

Дополнительные требования.

2.6.1.1. В требованиях к структуре и функционированию системы приводят:

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

2) требования к способам и средствам связи для информационного обмена между компонентами системы;

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

4) требования к режимам функционирования системы;

5) требования по диагностированию системы;

6) перспективы развития, модернизации системы.

2.6.1.2. В требованиях к численности и квалификации персонала АС приводят:

- требования к численности персонала (пользователей) АС;

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

- требуемый режим работы персонала АС.

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

Для АСУ указывают:

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

- допустимые пределы модернизации и развития системы;

- вероятностно-временные характеристики, при которых сохраняется целевое назначение системы.

2.6.1.4. В требования к надежности включают:

1) состав и количественные значения показателей надежности для системы в целом или ее подсистем;

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

3) требования к надежности технических средств и программного обеспечения;

4) требования к методам оценки и контроля показателей надежности на разных стадиях создания системы в соответствии с действующими нормативно-техническими документами.

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

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

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

2.6.1.8. В требования к эксплуатации, техническому обслуживанию, ремонту и хранению включают:

1) условия и регламент (режим) эксплуатации, которые должны обеспечивать использование технических средств (ТС) системы с заданными техническими показателями, в том числе виды и периодичность обслуживания ТС системы или допустимость работы без обслуживания;

2) предварительные требования к допустимым площадям для размещения персонала и ТС системы, к параметрам сетей энергоснабжения и т.п.;

3) требования по количеству, квалификации обслуживающего персонала и режимам его работы;

4) требования к составу, размещению и условиям хранения комплекта запасных изделий и приборов;

5) требования к регламенту обслуживания.

2.6.1.9. В требования к защите информации от несанкционированного доступа включают требования, установленные в НТД, действующей в отрасли (ведомстве) заказчика.

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

2.6.1.11. В требованиях к средствам защиты от внешних воздействий приводят:

1) требования к радиоэлектронной защите средств АС;

2) требования по стойкости, устойчивости и прочности к внешним воздействиям (среде применения).

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

2.6.1.13. В требования к стандартизации и унификации включают:

показатели, устанавливающие требуемую степень использования стандартных, унифицированных методов реализации функций (задач) системы, поставляемых программных средств, типовых математических методов и моделей, типовых проектных решений, унифицированных форм управленческих документов, установленных ГОСТ 6.10.1 *, общесоюзных классификаторов технико-экономической информации и классификаторов других категорий в соответствии с областью их применения, требования к использованию типовых автоматизированных рабочих мест, компонентов и комплексов.
_____________________
* На территории Российской Федерации действуют ПР 50.1.019-2000 .

2.6.1.14. В дополнительные требования включают:

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

2) требования к сервисной аппаратуре, стендам для проверки элементов системы;

3) требования к системе, связанные с особыми условиями эксплуатации;

4) специальные требования по усмотрению разработчика или заказчика системы.

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

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

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

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

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

4) перечень и критерии отказов для каждой функции, по которой задаются требования по надежности.

2.6.3. В подразделе "Требования к видам обеспечения" в зависимости от вида системы приводят требования к математическому, информационному, лингвистическому, программному, техническому, метрологическому, организационному, методическому и другим видам обеспечения системы.

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

2.6.3.2. Для информационного обеспечения системы приводят требования:

1) к составу, структуре и способам организации данных в системе;

2) к информационному обмену между компонентами системы;

3) к информационной совместимости со смежными системами;

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

5) по применению систем управления базами данных;

6) к структуре процесса сбора, обработки, передачи данных в системе и представлению данных;

7) к защите данных от разрушений при авариях и сбоях в электропитании системы;

8) к контролю, хранению, обновлению и восстановлению данных;

9) к процедуре придания юридической силы документам, продуцируемым техническими средствами АС (в соответствии с ГОСТ 6.10.4).

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

2.6.3.4. Для программного обеспечения системы приводят перечень покупных программных средств, а также требования:

1) к независимости программных средств от используемых СВТ и операционной среды;

2) к качеству программных средств, а также к способам его обеспечения и контроля;

3) по необходимости согласования вновь разрабатываемых программных средств с фондом алгоритмов и программ.

2.6.3.5. Для технического обеспечения системы приводят требования:

1) к видам технических средств, в том числе к видам комплексов технических средств, программно-технических комплексов и других комплектующих изделий, допустимых к использованию в системе;

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

2.6.3.6. В требованиях к метрологическому обеспечению приводят:

1) предварительный перечень измерительных каналов;

2) требования к точности измерений параметров и (или) к метрологическим характеристикам измерительных каналов;

3) требования к метрологической совместимости технических средств системы;

4) перечень управляющих и вычислительных каналов системы, для которых необходимо оценивать точностные характеристики;

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

6) вид метрологической аттестации (государственная или ведомственная) с указанием порядка ее выполнения и организаций, проводящих аттестацию.

2.6.3.7. Для организационного обеспечения приводят требования:

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

2) к организации функционирования системы и порядку взаимодействия персонала АС и персонала объекта автоматизации;

3) к защите от ошибочных действий персонала системы.

2.6.3.8. Для методического обеспечения САПР приводят требования к составу нормативно-технической документации системы (перечень применяемых при ее функционировании стандартов, нормативов, методик и т.п.).

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

В данном разделе также приводят:

1) перечень документов по ГОСТ 34.201 , предъявляемых по окончании соответствующих стадий и этапов работ;

2) вид и порядок проведения экспертизы технической документации (стадия, этап, объем проверяемой документации, организация-эксперт);

3) программу работ, направленных на обеспечение требуемого уровня надежности разрабатываемой системы (при необходимости);

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

2.8. В разделе "Порядок контроля и приемки системы" указывают:

1) виды, состав, объем и методы испытаний системы и ее составных частей (виды испытаний в соответствии с действующими нормами, распространяющимися на разрабатываемую систему);

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

3) статус приемочной комиссии (государственная, межведомственная, ведомственная).

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

В перечень основных мероприятий включают:

1) приведение поступающей в систему информации (в соответствии с требованиями к информационному и лингвистическому обеспечению) к виду, пригодному для обработки с помощью ЭВМ;

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

3) создание условий функционирования объекта автоматизации, при которых гарантируется соответствие создаваемой системы требованиям, содержащимся в ТЗ;

4) создание необходимых для функционирования системы подразделений и служб;

5) сроки и порядок комплектования штатов и обучения персонала.

Например, для АСУ приводят:

- изменения применяемых методов управления;

- создание условий для работы компонентов АСУ, при которых гарантируется соответствие системы требованиям, содержащимся в ТЗ.

2.10. В разделе "Требования к документированию" приводят:

1) согласованный разработчиком и заказчиком системы перечень подлежащих разработке комплектов и видов документов, соответствующих требованиям ГОСТ 34.201 и НТД отрасли заказчика; перечень документов, выпускаемых на машинных носителях; требования к микрофильмированию документации;

2) требования по документированию комплектующих элементов межотраслевого применения в соответствии с требованиями ЕСКД и ЕСПД;

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

2.11. В разделе "Источники разработки" должны быть перечислены документы и информационные материалы (технико-экономическое обоснование, отчеты о законченных научно-исследовательских работах, информационные материалы на отечественные, зарубежные системы-аналоги и др.), на основании которых разрабатывалось ТЗ и которые должны быть использованы при создании системы.

2.12. В состав ТЗ на АС при наличии утвержденных методик включают приложения, содержащие:

1) расчет ожидаемой эффективности системы;

2) оценку научно-технического уровня системы.

Приложения включают в состав ТЗ на АС по согласованию между разработчиком и заказчиком системы.

3. ПРАВИЛА ОФОРМЛЕНИЯ

3.1. Разделы и подразделы ТЗ на АС должны быть размещены в порядке, установленном в разд.2 настоящего стандарта.

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

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

3.3. Значения показателей, норм и требований указывают, как правило, с предельными отклонениями или максимальным и минимальным значениями. Если эти показатели, нормы, требования однозначно регламентированы НТД, в ТЗ на АС следует приводить ссылку на эти документы или их разделы, а также дополнительные требования, учитывающие особенности создаваемой системы. Если конкретные значения показателей, норм и требований не могут быть установлены в процессе разработки ТЗ на АС, в нем следует сделать запись о порядке установления и согласования этих показателей, норм и требований:

"Окончательное требование (значение) уточняется в процессе... и согласовывается протоколом с... на стадии...". При этом в текст ТЗ на АС изменений не вносят.

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

Форма титульного листа ТЗ на АС приведена в приложении 2. Форма последнего листа ТЗ на АС приведена в приложении 3.

3.5. При необходимости на титульном листе ТЗ на АС допускается помещать установленные в отрасли коды, например: гриф секретности, код работы, регистрационный номер ТЗ и др.

3.6. Титульный лист дополнения к ТЗ на АС оформляют аналогично титульному листу технического задания. Вместо наименования "Техническое задание" пишут "Дополнение N ... к ТЗ на АС …".

3.7. На последующих листах дополнения к ТЗ на АС помещают основание для изменения, содержание изменения и ссылки на документы, в соответствии с которыми вносятся эти изменения.

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

ПРИЛОЖЕНИЕ 1 (рекомендуемое). ПОРЯДОК РАЗРАБОТКИ, СОГЛАСОВАНИЯ И УТВЕРЖДЕНИЯ ТЗ НА АС

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

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

2. Необходимость согласования проекта ТЗ на АС с органами государственного надзора и другими заинтересованными организациями определяют совместно заказчик системы и разработчик проекта ТЗ на АС.

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

3. Срок согласования проекта ТЗ на АС в каждой организации не должен превышать 15 дней со дня его получения. Рекомендуется рассылать на согласование экземпляры проекта ТЗ на АС (копий) одновременно во все организации (подразделения).

4. Замечания по проекту ТЗ на АС должны быть представлены с техническим обоснованием. Решения по замечаниям должны быть приняты разработчиком проекта ТЗ на АС и заказчиком системы до утверждения ТЗ на АС.

5. Если при согласовании проекта ТЗ на АС возникли разногласия между разработчиком и заказчиком (или другими заинтересованными организациями), то составляется протокол разногласий (форма произвольная) и конкретное решение принимается в установленном порядке.

6. Согласование проекта ТЗ на АС разрешается оформлять отдельным документом (письмом). В этом случае под грифом "Согласовано" делают ссылку на этот документ.

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

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

9. Копии утвержденного ТЗ на АС в 10-дневный срок после утверждения высылаются разработчиком ТЗ на АС участникам создания системы.

10. Согласование и утверждение дополнений к ТЗ на АС проводят в порядке, установленном для ТЗ на АС.

11. Изменения к ТЗ на АС не допускается утверждать после представления системы для ее очереди на приемосдаточные испытания.

12. Регистрация, учет и хранение ТЗ на АС и дополнений к нему проводят в соответствии с требованиями ГОСТ 2.501 .

наименование организации - разработчика ТЗ на АС
УТВЕРЖДАЮ		УТВЕРЖДАЮ
Руководитель (должность, наименование предприятия - заказчика АС)		Руководитель (должность, наименование предприятия - разработчика АС)
Личная подпись	Расшифровка подписи	Личная подпись	Расшифровка подписи
наименование вида АС
наименование объекта автоматизации
сокращенное наименование АС

ТЕХНИЧЕСКОЕ ЗАДАНИЕ

Действует с
СОГЛАСОВАНО
Руководитель (должность, наименование согласующей организации)
Личная подпись	Расшифровка подписи

СОСТАВИЛИ

	Должность исполнителя	Фамилия, имя, отчество

СОГЛАСОВАНО

Наименование организации, предприятия	Должность	Фамилия, имя, отчество

Электронный текст документа
подготовлен АО "Кодекс" и сверен по:
официальное издание
М.: Стандартинформ, 2009

ГОСТ 34.602-89 Информационная технология (ИТ). Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы

Название документа:
Номер документа:	34.602-89
Вид документа:	ГОСТ
Принявший орган:	Госстандарт СССР
Статус:	Действующий
Опубликован:	Официальное издание. М.: Стандартинформ, 2009 год Информационная технология. Автоматизированные системы. Основные положения: Сб. ГОСТов. - М.: ИПК Издательство стандартов, 2002 год
Дата принятия:	24 марта 1989
Дата начала действия:	01 января 1990
Дата редакции:	01 июня 2009

ГОСТ 34.602-89 Информационная технология (ИТ). Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы

стр. 1

стр. 2

стр. 3

стр. 4

стр. 5

стр. 6

стр. 7

стр. 8

стр. 9

стр. 10

стр. 11

стр. 12

МЕЖГОСУДАРСТВЕННЫЙ СТАНДАРТ

ИНФОРМАЦИОННАЯ
ТЕХНОЛОГИЯ

Комплекс стандартов
на автоматизированные системы.
Техническое задание на создание
автоматизированной системы

Дата введения 01.01.90

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

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

1.1. ТЗ на АС является основным документом, определяющим требования и порядок создания (развития или модернизации - далее создания) автоматизированной системы, в соответствии с которым проводится разработка АС и ее приемка при вводе в действие.

1.2. ТЗ на АС разрабатывают на систему в целом, предназначенную для работы самостоятельно или в составе другой системы.

Дополнительно могут быть разработаны ТЗ на части АС; на подсистемы АС, комплексы задач АС и т. п. в соответствии с требованиями настоящего стандарта; на комплектующие средства технического обеспечения и программно-технические комплексы в соответствии со стандартами ЕСКД и СРПП; на программные средства в соответствии со стандартами ЕСПД; на информационные изделия в соответствии с ГОСТ 19.201 и НТД, действующей в ведомстве заказчика АС.

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

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

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

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

1.5. ТЗ на АС разрабатывают на основании исходных данных, в том числе содержащихся в итоговой документации стадии «Исследование и обоснование создания АС», установленной ГОСТ 34.601 .

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

1.7. Изменения к ТЗ на АС оформляют дополнением или подписанным заказчиком и разработчиком протоколом. Дополнение или указанный протокол являются неотъемлемой частью ТЗ на АС. На титульном листе ТЗ на АС должна быть запись «Действует с … ».

2. СОСТАВ И СОДЕРЖАНИЕ

2.1. ТЗ на АС содержит следующие разделы, которые могут быть разделены на подразделы:

1) общие сведения;

2) назначение и цели создания (развития) системы;

3) характеристика объектов автоматизации;

4) требования к системе;

5) состав и содержание работ по созданию системы;

6) порядок контроля и приемки системы;

7) требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие;

8) требования к документированию;

9) источники разработки.

В ТЗ на АС могут включаться приложения.

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

В ТЗ на части системы не включают разделы, дублирующие содержание разделов ТЗ на АС в целом.

2.3. В разделе «Общие сведения» указывают:

1) полное наименование системы и ее условное обозначение;

2) шифр темы или шифр (номер) договора;

3) наименование предприятий (объединений) разработчика и заказчика (пользователя) системы и их реквизиты;

4) перечень документов, на основании которых создается система, кем и когда утверждены эти документы;

5) плановые сроки начала, и окончания работы по созданию системы;

6) сведения об источниках и порядке финансирования работ;

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

2.4. Раздел «Назначение и цели создания (развития) системы» состоит из подразделов:

1) назначение системы;

2) цели создания системы.

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

Для АСУ дополнительно указывают перечень автоматизируемых органов (пунктов) управления и управляемых объектов.

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

2.5. В разделе «Характеристики объекта автоматизации» приводят:

1) краткие сведения об объекте автоматизации или ссылки на документы, содержащие такую информацию;

2) сведения об условиях эксплуатации объекта автоматизации и характеристиках окружающей среды.

Примечание. Для САПР в разделе дополнительно приводят основные параметры и характеристики объектов проектирования.

2.6. Раздел «Требования к системе» состоит из следующих подразделов:

1) требования к системе в целом;

2) требования к функциям (задачам), выполняемым системой;

3) требования к видам обеспечения.

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

2.6.1. В подразделе «Требования к системе в целом» указывают:

Требования к структуре и функционированию системы;

Требования к численности и квалификации персонала системы и режиму его работы;

Показатели назначения;

Требования к надежности;

Требования безопасности;

Требования к эргономике и технической эстетике;

Требования к транспортабельности для подвижных АС;

Требования к эксплуатации, техническому обслуживанию, ремонту и хранению компонентов системы;

Требования к защите информации от несанкционированного доступа;

Требования по сохранности информации при авариях;

Требования к защите от влияния внешних воздействии;

Требования к патентной чистоте;

Требования по стандартизации и унификации;

Дополнительные требования.

2.6.1.1. В требованиях к структуре и функционированию системы приводят:

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

2) требования к способам и средствам связи для информационного обмена между компонентами системы;

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

4) требования к режимам функционирования системы;

5) требования по диагностированию системы;

6) перспективы развития, модернизации системы.

2.6.1.2. В требованиях к численности и квалификации персонала АС приводят:

Требования к численности персонала (пользователей) АС;

Требования к квалификации персонала, порядку его подготовки и контроля знаний и навыков;

Требуемый режим работы персонала АС.

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

Для АСУ указывают:

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

Допустимые пределы модернизации и развития системы;

Вероятностно-временные характеристики, при которых сохраняется целевое назначение системы.

2.6.1.4. В требования к надежности включают:

1) состав и количественные значения показателей надежности для системы в целом или ее подсистем;

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

3) требования к надежности технических средств и программного обеспечения;

4) требования к методам оценки и контроля показателей надежности на разных стадиях создания системы в соответствии с действующими нормативно-техническими документами.

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

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

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

2.6.1.8. В требования к эксплуатации, техническому обслуживанию, ремонту и хранению включают:

1) условия и регламент (режим) эксплуатации, которые должны обеспечивать использование технических средств (ТС) системы с заданными техническими показателями, в том числе виды и периодичность обслуживания ТС системы или допустимость работы без обслуживания;

2) предварительные требования к допустимым площадям для размещения персонала и ТС системы, к параметрам сетей энергоснабжения и т. п.;

3) требования по количеству, квалификации обслуживающего персонала и режимам его работы;

4) требования к составу размещению и условиям хранения комплекта запасных изделий и приборов;

5) требования к регламенту обслуживания.

2.6.1.9. В требования к защите информации от несанкционированного доступа включают требования, установленные в НТД, действующей в отрасли (ведомстве) заказчика.

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

2.6.1.11. В требованиях к средствам защиты от внешних воздействии приводят:

1) требования к радиоэлектронной защите средств АС;

2) требования по стойкости, устойчивости и прочности к внешним воздействиям (среде применения).

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

2.6.1.13. В требования к стандартизации и унификации включают:

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

* На территории Российской Федерации действуют ПР 50.1.019-2000 .

2.6.1.14. В дополнительные требования включают:

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

2) требования к сервисной аппаратуре, стендам для проверки элементов системы;

3) требования к системе, связанные с особыми условиями эксплуатации;

4) специальные требования по усмотрению разработчика или заказчика системы.

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

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

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

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

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

4) перечень и критерии отказов для каждой функции, по которой задаются требования по надежности.

2.6.3. В подразделе «Требования к видам обеспечения» в зависимости от вида системы приводят требования к математическому, информационному, лингвистическому, программному, техническому, метрологическому, организационному, методическому и другим видам обеспечения системы.

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

2.6.3.2. Для информационного обеспечения системы приветят требования:

1) к составу, структуре и способам организации данных в системе;

2) к информационному обмену между компонентами системы;

3) к информационной совместимости со смежными системами;

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

5) по применению систем управления базами данных;

6) к структуре процесса сбора, обработки, передачи данных в системе и. представлению данных;

7) к защите данных от разрушений при авариях и сбоях в электропитании системы;

8) к контролю, хранению, обновлению и восстановлению данных;

9) к процедуре придания юридической силы документам, продуцируемым техническими средствами АС (в соответствии с ГОСТ 6.10.4).

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

2.6.3.4. Для программного обеспечения системы приводят перечень покупных программных средств, а также требования:

1) к независимости программных средств от используемых СВТ и операционной среды;

2) к качеству программных средств, а также к способам его обеспечения и контроля;

3) по необходимости согласования вновь разрабатываемых программных средств с фондом алгоритмов и программ.

2.6.3.5. Для технического обеспечения системы приводят требования:

1) к видам технических средств, в том числе к видам комплексов технических средств, программно-технических комплексов и других комплектующих изделий, допустимых к использованию в системе;

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

2.6.3.6. В требованиях к метрологическому обеспечению приводят:

1) предварительный перечень измерительных каналов;

2) требования к точности измерений параметров и (или) к метрологическим характеристикам измерительных каналов;

3) требования к метрологической совместимости технических средств системы;

4) перечень управляющих и вычислительных каналов системы, для которых необходимо оценивать точностные характеристики;

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

6) вид метрологической аттестации (государственная или ведомственная) с указанием порядка ее выполнения и организаций, проводящих аттестацию.

2.6.3.7. Для организационного обеспечения приводят требования:

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

2) к организации функционирования системы и порядку взаимодействия персонала АС и персонала объекта автоматизации;

3) к защите от ошибочных действий персонала системы.

2.6.3.8. Для методического обеспечения САПР приводят требования к составу нормативно-технической документации системы (перечень применяемых при ее функционировании стандартов, нормативов, методик и т. п.).

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

В данном разделе также приводят:

ПРИЛОЖЕНИЕ 2

ФОРМА ТИТУЛЬНОГО ЛИСТА ТЗ НА АС

_________________________________________________________________________ наименование организации - разработчика ТЗ на АС
УТВЕРЖДАЮ		УТВЕРЖДАЮ
Руководитель (должность, наименование предприятия–заказчика АС)		Руководитель (должность, наименование предприятия–разработчика АС)
Личная подпись	Расшифровка подписи	Личная подпись	Расшифровка подписи
наименование вида АС ___________________________________________________________________________ наименование объекта автоматизации ___________________________________________________________________________ сокращенное наименование АС
ТЕХНИЧЕСКОЕ ЗАДАНИЕ На________ листах Действует с

ПРИЛОЖЕНИЕ 3

ФОРМА ПОСЛЕДНЕГО ЛИСТА ТЗ НА АС

____________________

СОСТАВИЛИ

СОГЛАСОВАНО

ИНФОРМАЦИОННЫЕ ДАННЫЕ

1. РАЗРАБОТАН И ВНЕСЕН Государственным комитетом СССР по стандартам Министерством приборостроения, средств автоматизации и систем управления СССР