cit.sakhalin.gov.ru · Web view4.1.9.1 Технические требования по защите информации29 4.1.10 Требования по сохранности

<НАИМЕНОВАНИЕ ЗАКАЗЧИКА>

ТЕХНИЧЕСКОЕ ЗАДАНИЕ НА СОЗДАНИЕ/РАЗВИТИЕ ИНФОРМАЦИОННОЙ СИСТЕМЫ

На 6260 листах

<Город><Год издания>

Легенда:РекомендацииПримерыОбязательные вставки

Содержание1 Общие сведения 6

1.1 Полное наименование системы 6

1.2 Условное обозначение системы 6

1.3 Заказчик 6

1.4 Пользователь 6

1.5 Исполнитель 6

1.6 Основание для разработки Системы 7

1.7 Плановые сроки разработки Системы 7

1.8 Источник финансирования 7

1.9 Порядок финансирования 7

1.10 Порядок оформления и предъявления Заказчику результатов работ 7

1.11 Перечень нормативно-технических документов, методических материалов, регламентирующих разработку Системы 7

1.12 Перечень сокращений 8

1.13 Термины и определения, используемые в ТЗ 8

1.14 Порядок внесения изменений и дополнений 92 Назначение и цели создания (развития) системы 10

2.1 Назначение системы 10

2.2 Цели и задачи выполнения работ 103 Характеристики объектов автоматизации 11

3.1 Краткие сведения об объекте автоматизации 11

3.2 Сведения об условиях эксплуатации объекта автоматизации и характеристиках окружающей среды 113.2.1 Условия эксплуатации комплекса технических средств 113.2.2 Характеристики окружающей среды 11

3.3 Описание места объекта автоматизации в совокупности окружающих автоматизированных информационных систем 123.3.1 Сведения о внешней среде 123.3.2 Основные функции взаимодействующих сторон 12

3.4 Текущее состояние объекта автоматизации 12

3.5 Общие принципы создания Системы 124 Требования к системе 14

4.1 Требования к системе в целом 144.1.1 Требования к структуре и функционированию системы 14

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

обмена между компонентами системы 164.1.1.3 Требования по взаимосвязям системы с внешними и со смежными

системами, обеспечению ее совместимости 16


4.1.1.4 Требования к режимам функционирования системы 174.1.1.5 Требования по диагностированию системы 184.1.1.6 Перспективы развития, модернизации системы 18

4.1.2 Требования к численности и квалификации персонала системы и режиму его работы, требования к квалификации пользователей системы и режиму их работы 184.1.2.1 Требования к численности персонала Системы 194.1.2.2 Требования к квалификации персонала, порядку его подготовки и

контроля знаний и навыков 194.1.2.3 Требуемый режим работы персонала Системы 204.1.2.4 Требования к квалификации пользователей системы 204.1.2.5 Требуемый режим работы пользователей Системы 20

4.1.3 Показатели назначения 204.1.3.1 Количество пользователей 204.1.3.2 Число обрабатываемых объектов 214.1.3.3 Пропускная способность 224.1.3.4 Время получения отчетности 23

4.1.4 Требования к надежности 254.1.4.1 Показатели доступности/надежности 254.1.4.2 Требования к программным мероприятиям по обеспечению

надежности 264.1.5 Требования к безопасности 264.1.6 Требования к эргономике и технической эстетике 264.1.7 Требования к транспортабельности для подвижных АС 274.1.8 Требования к эксплуатации, техническому обслуживанию, ремонту и хранению

компонентов системы 274.1.8.1 Условия и регламент (режим) промышленной эксплуатации 274.1.8.2 Требования по количеству, квалификации обслуживающего персонала

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

запасных изделий и приборов 274.1.8.4 Требования к регламенту обслуживания 28

4.1.9 Требования к защите информации от несанкционированного доступа 294.1.9.1 Технические требования по защите информации 29

4.1.10 Требования по сохранности информации при авариях 314.1.10.1 Перечень событий, при которых должна быть обеспечена

сохранность информации в системе 324.1.10.2 Требования к регламентам и объемам резервного копирования и

архивирования данных 324.1.11 Требования к патентной чистоте и защите авторских прав 32

4.1.11.1 Перечень стран, в отношении которых должна быть обеспечена патентная чистота системы и ее частей 32

4.1.11.2 Требования к использованию лицензионного программного обеспечения 33

4.1.12 Требования по стандартизации и унификации 334.1.13 Дополнительные требования 34

4.1.13.1 Требования к оснащению системы устройствами для обучения персонала и документацией на них 34


4.1.13.2 Требования к Системе, связанные с особыми условиями эксплуатации 34

4.1.13.3 Требования по сертификации Системы, ее компонентов 344.1.13.4 Специальные требования 34

4.1.14 Требования к электронным учебным курсам 344.1.14.1 Требования по соответствию электронных курсов международным

стандартам 344.1.14.2 Требования к формату используемых в курсе файлов 344.1.14.3 Требования к просмотру электронных курсов через браузер 35

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

354.2.1.1 Сценарий <название сценария> 35

4.2.2 Требования к функциям подсистемы … 364.2.2.1 Требования к функциям модуля … 36

4.2.3 Требования к АРМ … 374.2.3.1 Требования к форме 37

4.3 Требования к видам обеспечения 374.3.1 Требования к математическому обеспечению 374.3.2 Требования к информационному обеспечению 37

4.3.2.1 Требования к составу, структуре и способам организации данных в системе 37

4.3.2.2 Требования к организации ввода данных в систему 384.3.2.3 Требования к информационному обмену между компонентами

системы 384.3.2.4 Объем и состав информации, получаемой из классификаторов 384.3.2.5 Требования к разработке дополнительных классификаторов 384.3.2.6 Требования по применению систем управления базами данных 384.3.2.7 Требования к структуре процесса сбора, обработки, передачи данных

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

электропитании системы 394.3.2.9 Требования к контролю, хранению, обновлению и восстановлению

данных 394.3.3 Требования к лингвистическому обеспечению 394.3.4 Требования к программному обеспечению 394.3.5 Требования к техническому обеспечению 404.3.6 Требования к метрологическому обеспечению 404.3.7 Требования к телекоммуникационному обеспечению системы 40

4.3.7.1 Необходимые линии и каналы связи 404.3.7.2 Среда передачи 404.3.7.3 Технические параметры каналов связи 404.3.7.4 Пропускная способность, интерфейсы, топология и т.п. 404.3.7.5 Необходимость организации новых каналов связи. 40

4.3.8 Требования к другим видам обеспечения 405 Состав и содержание работ по созданию системы 41

5.1 Этапы работ 41

5.2 Дополнительные сведения 44


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

6.1 Виды, состав, объем и методы испытаний системы и ее составных частей 45

6.2 Общие требования к приемке работ по стадиям 456.2.1 Порядок сдачи-приемки результатов работ по Этапу 1. 46

6.2.1.1 Порядок сдачи результатов работ по пункту 1.1. Календарного плана46

6.2.1.2 Порядок сдачи результатов работ по пункту 1.2. Календарного плана47

6.2.1.3 Порядок сдачи результатов работ, указанных в пункте 1.3. Календарного плана 47

6.2.2 Порядок сдачи-приемки результатов работ по Этапу 2 486.2.3 Порядок сдачи-приемки результатов работ по Этапу 3 486.2.4 Порядок сдачи-приемки результатов работ по Этапу 4. 49

6.3 Сведения о гарантийном обслуживании системы 49

6.4 Порядок выполнения доработок и устранения допущенных Исполнителем ошибок, которые выявлены в процессе испытаний и в период гарантийного обслуживания50

6.5 Статус приемочной комиссии 50

6.6 Сведения об обслуживании системы 507 Требования к составу и содержанию работ по подготовке объекта автоматизации к

вводу системы в действие 52

7.1 Развертывание и конфигурирование 52

7.2 Приведение поступающей в систему информации к виду, пригодному для обработки с помощью ЭВМ 52

7.3 Изменения, которые необходимо осуществить в объекте автоматизации 537.3.1 Создание условий функционирования объекта автоматизации, при которых

гарантируется соответствие создаваемой системы требованиям 537.3.2 Создание необходимых для функционирования системы подразделений и

служб 537.3.3 Сроки и порядок комплектования штатов и обучения персонала 53

8 Требования к документированию 549 Источники разработки 58

9.1 Список литературы 58

9.2 Нормативные документы 58

9.3 Нормативно-правовые акты 58

9.4 Нормативно-методические документы 58

9.5 Нормативно-технические документы 58Приложения 60


1 Общие сведения[В разделе должны быть приведены:

1) Полное наименование системы и ее условное обозначение.2) Наименование организаций Заказчика и Функционального заказчика, их

реквизиты.3) Перечень документов, на основании которых создается1 система, кем и когда

утверждены эти документы.4) Пользователь системы. В настоящем разделе должны быть указаны только

организации, в отношении которых создается Система5) Информация об исполнителе6) Плановые сроки начала и окончания работы по созданию системы.7) Сведения об источниках и порядке финансирования работ.8) Порядок оформления и предъявления Заказчику результатов работ по созданию

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

9) Перечень нормативно-технических документов, методических материалов, регламентирующих разработку Системы.

10) Перечень принятых терминов, сокращений и определений].

1.1 Полное наименование системы[Полное наименование системы].

1.2 Условное обозначение системы [Условное обозначение системы].

1.3 Заказчик[В разделе должны быть приведены:

1) Государственный заказчик (наименование, юридический адрес и адрес переписки).

2) Функциональный заказчик – ОИВ, ответственный за реализацию процесса, автоматизируемого системой (наименование, юридический адрес и адрес переписки).

1.4 ПользовательПользователем Системы является: <наименование организации>.Юридический адрес: <юридический адрес>.Адрес для переписки: <адрес для переписки>.

1.5 ИсполнительОпределяется по результатам проведения конкурсной процедуры в соответствии с

федеральным законом 5 апреля 2013 года N 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд».

1 Объектом ТЗ может быть разработка или модификация Системы. Далее в шаблоне будет использован термин «создание».


1.6 Основание для разработки Системы[Основанием для разработки Системы являются документы, на основании которых

создается система, с указанием того, кем и когда утверждены эти документы].

1.7 Плановые сроки разработки СистемыСрок начала работ: с момента заключения контракта.Срок окончания работ: не позднее <дата окончания работ>.Сроки начала и окончания стадий и этапов работ уточняются соответствующими

договорами на выполнение этапов работ на основе сроков, приведенных в разделе 5 настоящего ТЗ.

1.8 Источник финансированияФинансирование работ осуществляется за счет средств бюджета < >.

1.9 Порядок финансированияПорядок финансирования работ определяется действующими нормативно-

правовыми актами Правительства Сахалинской области

1.10 Порядок оформления и предъявления Заказчику результатов работПорядок оформления и предъявления Заказчику результатов работ по созданию

Системы приведен в разделах 5, 6 и 8 данного ТЗ.Документация передается на бумажных (два экземпляра) и на машинных носителях

(CD|DVD). Текстовые документы, передаваемые на машинных носителях, должны быть представлены в форматах Microsoft Office.

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

1.11 Перечень нормативно-технических документов, методических материалов, регламентирующих разработку Системы[В разделе должны быть приведены документы, регламентирующие разработку

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

1. В случае, если Система предназначена для реализации государственных функций или реализации государственных услуг – в данный раздел в обязательном порядке должен включаться Приказ ФСТЭК России от 11 февраля 2013 года № 17 «Об утверждении требований о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах».

2. В случае, если Система обрабатывает персональные данные и является государственной системой – в данный раздел в обязательном порядке должно включаться Постановление Правительства Российской Федерации от 1 ноября 2012 г. N 1119 «Об утверждении требований к защите персональных данных при их обработке в информационных системах персональных данных».

3. В случае, если Система обрабатывает персональные данные и не является государственной системой – в данный раздел в обязательном порядке должен включаться Приказ ФСТЭК России от 18 февраля 2013 года № 21 «Об


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

В случае если анализ нормативной документации не проводился на стадии подготовки ТЗ, необходимо вставить фразу «Полный перечень нормативных документов, регламентирующих порядок создания Системы, определяется Исполнителем в рамках обследования объекта автоматизации на этапе предварительного / технического проектирования и приводится в Частном техническом задании».

1.12 Перечень сокращенийБД — База данных

ГОСТ — Государственный стандарт

ГУ — Государственные услуги

ЭП — Электронная подпись

АИС — Автоматизированная информационная система

ИС — Информационная система

ТЗ — Техническое задание

ЧТЗ — Частное техническое задание

1.13 Термины и определения, используемые в ТЗ[В настоящем разделе должны быть приведены все термины и определения,

используемые в ТЗ].[В случае, если Система обрабатывает персональные данные, в документе должны

употребляться актуальные определения из закона «О персональных данных»].Абонент — Лицо, обладающее правом пользования какой-либо услугой

Авторизация — Разрешение для проведения операций с использованием платежной карты

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

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

Заказчик — Государственный заказчик: <Наименование организации заказчика>

Исполнитель — Исполнитель по Государственному контракту. Приложением к Государственному контракту является настоящий документ

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

Несанкционированный доступ

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


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

Обслуживающий персонал

— Сотрудники ЦОД <наименование организации>, выполняющие работы по обслуживанию системы, также сотрудники организации, обслуживающей систему в рамках контракта на эксплуатацию

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

Персональные данные — Персональные данные — согласно Федеральному закону РФ от 27 июля 2006 г. № 152-ФЗ «О персональных данных», любая информация, относящаяся к определенному или определяемому на основании такой информации физическому лицу (субъекту персональных данных), в том числе его фамилия, имя, отчество, год, месяц, дата и место рождения, адрес, семейное, социальное, имущественное положение, образование, профессия, доходы, другая информация

Пользователь — Организация в отношении которой создается Система, также, сотрудник такой организации, использующий систему в работе

Регламент — Совокупность правил, устанавливающих порядок проведения работ

Функциональный заказчик

— ОИВ, ответственный за реализацию процесса, автоматизируемого системой

1.14 Порядок внесения изменений и дополненийИзменения настоящего ТЗ не предусмотрены. Детализация и дополнение требований

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


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

2.1 Назначение системы[В подразделе должны быть указаны виды автоматизируемой деятельности и

перечень подразделений/пользователей/площадок/объектов, которые затронет автоматизация. Перечисленные виды деятельности должны быть позднее на этапе проектирования детально описаны в пояснительной записке в разделе с описанием процессов деятельности.

Перечень приведенных в данном подразделе автоматизируемых видов деятельности определяет состав функциональных подсистем системы, приводимый ниже в п. 4.1.1 и в п. 4.2. Каждый вид деятельности имеет конечную цель, достижение которой должно быть обозначено ниже в показателях назначения в п. 4.1.2 .]

2.2 Цели и задачи выполнения работ[В подразделе должны быть приведены наименования и требуемые значения

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

В случае модернизации системы, также должны присутствовать относительные критерии достижения целей (на какое количество шт./%/часов/минут должно что-то стать меньше/больше/делаться быстрее в результате модернизации).

Цели создания Системы и выполнения работ должны коррелировать с показателями назначения (п. 4.1.3 . Показатели назначения)

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


3 Характеристики объектов автоматизации[В разделе должны быть изложены: краткие сведения об объекте автоматизации или ссылки на документы,

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

характеристиках окружающей среды].

3.1 Краткие сведения об объекте автоматизации[Объектом автоматизации является деятельность пользователей системы. Каждая

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

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

3.2.1 Условия эксплуатации комплекса технических средств[В данном разделе приводятся условия промышленной эксплуатации клиентских

технических средств.Система должна размещаться на ресурсах ЦОД Правительства Сахалинской области,

используя имеющуюся виртуальную инфраструктуру ЦОД на базе VMware. В случае отсутствия технической возможности размещения Системы на имеющихся ресурсах, необходимо аргументированно описать причины.]

Условия эксплуатации комплекса технических средств Системы должны соответствовать условиям эксплуатации группы 2 ГОСТ 21552-84 «Средства вычислительной техники. Общие технические требования, приемка, методы испытаний, маркировка, упаковка, транспортировка, хранение».

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

Комплекс технический средств располагается в ЦОД Правительства Сахалинской области.

Исполнитель должен проверить соблюдение условий эксплуатации комплекса технических средств на этапе технического проектирования.

3.2.2 Характеристики окружающей среды[В данном разделе приводятся характеристики окружающей среды на рабочих

местах пользователей.]Характеристики окружающей среды в местах установки технических средств

соответствуют требованиям следующих документов: ГОСТ Р ИСО 14001-98. Системы управления окружающей средой. Требования

и руководство по применению;


СанПиН 2.2.24.548-96. Физические факторы производственной среды. Гигиенические требования к микроклимату производственных помещений;

СанПиН 2.2.2/2.4.1340-03. Гигиенические требования к персональным электронно-вычислительным машинам и организации работы.

3.3 Описание места объекта автоматизации в совокупности окружающих автоматизированных информационных систем

3.3.1 Сведения о внешней среде[Здесь должно быть приведено описание IT-ландшафта, т. е. существующие системы,

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

3.3.2 Основные функции взаимодействующих сторон[Здесь приводится описание возможных случаев взаимодействия, выявленных к

моменту составления технического задания].

3.4 Текущее состояние объекта автоматизации[Здесь должно быть приведено описание проектов, которые уже идут на объекте

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

3.5 Общие принципы создания СистемыВ соответствии с РД 50-680–88 при создании Системы необходимо

руководствоваться следующими принципами:1) Принцип системности

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

2) Принцип развития (открытости)Исходя из перспектив развития объекта автоматизации, система должна создаваться

с учетом возможности пополнения и обновления функций и состава системы без нарушения ее функционирования.

3) Принцип совместимостиДолжны быть реализованы информационные интерфейсы, благодаря которым

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

4) Принцип стандартизации (унификации)Должны быть рационально применены типовые, унифицированные и

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

5) Принцип эффективностиДолжно быть достигнуто рациональное соотношение между затратами на создание

системы и целевыми эффектами, включая конечные результаты, получаемые в результате автоматизации.

[Дополнительны варианты принципов].


1) Принцип концептуального единстваСистема должна разрабатываться в соответствии утвержденными нормативно-

правовыми актами РФ и субъектов РФ, нормативно-методическими и нормативно-техническими документами, регламентирующими порядок создания, разработки и эксплуатации автоматизированных систем.

2) Принцип развития (модифицируемости)Система должна обеспечивать возможность развития, расширения и интеграции с

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

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

3) Принцип мобильностиВсе виды обеспечения проектируемой Системы должны обладать максимальной

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

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

5) Принцип относительной независимости подсистем (принцип модульности)Система должна быть реализована как совокупность отдельных максимально

независимых функциональных подсистем.6) Принцип открытости

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

7) Принцип многоуровневостиПроцесс предоставления государственных, муниципальных и иных услуг имеет

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

каждом уровне.8) Принцип санкционированного доступа к информации

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


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

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

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

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

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

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

требования к режимам функционирования системы; требования по диагностированию системы; перспективы развития, модернизации системы].

Система должна представлять собой открытую информационную систему и интегрируемую с другими информационными ресурсами.

Модули системы должны разрабатываться с учетом многоуровневой архитектуры.Уровень представления должен быть отделен от уровня данных слоем бизнес-

логики.

Рис 1. Типовая схема трёхуровневой архитектуры

4.1.1.1 Перечень подсистем, их назначение и основные характеристики[Текущий раздел описывает логическую и физическую архитектуру системы,

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


собираться при сборке в отдельные элементы/шаблоны. Элементы, входящие в состав Системы, формируют предварительный список раздела 4 Описания архитектуры.

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

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

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

Группирование функциональности в самостоятельную подсистему должно производиться по следующим принципам:

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

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

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

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

Подсистема управления информационным взаимодействием; Подсистема информационной безопасности; Репозиторий (управление метаданными).

Для каждой выделенной подсистемы должно быть приведено: назначение подсистемы (обозначены подпроцессы основного процесса,

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

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

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

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

подсистемы: подсистема администрирования; подсистема мониторинга; подсистема управления взаимодействием;

Исполнитель на этапе предварительного проектирования должен разработать или актуализировать и согласовать с Заказчиком архитектуру решения. Архитектура решения должна быть оформлена в соответствии с документом «Шаблон описания архитектуры». Решение по архитектуре должно отвечать, в том числе, нефункциональным требованиям, предъявляемым к системе.

4.1.1.1.1 Подсистема Администрирования

[По каждой подсистеме должны быть приведены: назначение, состав модулей и АРМ, необходимость которых уже выявлена на момент разработки документа для ТЗ и в обязательном порядке для ЧТЗ. Помимо этого, могут быть указаны требования, касающиеся конструктивных особенностей подсистем и их основных характеристик]

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

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


В состав подсистемы Администрирования должны входить следующие АРМ

пользователей:

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

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

В качестве протокола взаимодействия между компонентами Системы на транспортно-сетевом уровне необходимо использовать протокол TCP/IP.

Информационное взаимодействие между компонентами системы осуществляется посредством доступа к единому хранилищу данных (СУБД).

Для организации информационного обмена между компонентами Системы должны использоваться специальные протоколы прикладного уровня.

4.1.1.3 Требования по взаимосвязям системы с внешними и со смежными системами, обеспечению ее совместимости

[В разделе обязательно должен быть определен перечень систем, с которыми обязательно должно быть обеспечено взаимодействие. В случае наличия документации, определяющей порядок взаимодействия с этими системами, в разделе должны быть приведены ссылки на эти документы. Должно быть указано:

в части какой информации (объектов, справочников) должен происходить обмен с внешними и смежными системами;

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

Должно быть указано, что на этапе предварительного проектирования точный состав внешних систем должен быть определен Исполнителем на основании анализа нормативной базы и обследования объекта автоматизации (процессов автоматизируемой деятельности). При этом по результатам анализа/обследования может быть выявлена как необходимость взаимодействия, так и отсутствие такой необходимости. При выявлении необходимости взаимодействия порядок взаимодействия должен быть описан в виде перечня случаев взаимодействия и результатов взаимодействия в Отчете об обследовании объекта автоматизации и/или в соответствующих ЧТЗ.]

4.1.1.3.1 Требования по интеграции с АИС «Предоставления государственных и муниципальных услуг Сахалинской области в электронной форме» (АИС «ПГМУ»)

Должно быть разработано ТЗ на создание интерактивной формы в АИС «ПГМУ» в соответствии с шаблоном (Приложение 1 к настоящему ТЗ).

Взаимодействие c АИС «ПГМУ» должно осуществляться посредством веб-сервисов.Система должна обеспечивать следующую функциональность: формирование и отправку запросов в АИС «ПГМУ»; предоставление данных ведомственных словарей, классификаторов и других

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

за определенный период по запросам из АИС «ПГМУ»;


предоставление детальных сведений об обращениях по запросам из АИС «ПГМУ»;

гарантированную доставку сообщений; регистрацию в АИС «ПГМУ» статусов оказания услуги Заявителю; подписание ЭП всех сведений, передаваемых при взаимодействии с АИС

«ПГМУ».

4.1.1.3.2 Требования по интеграции с ГЕО ИС.

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

Функционирование картографической подсистемы (модуль, блок) осуществляется путем взаимодействия с ГЕО ИС и организовано на принципах и с применением специального API (application programming interface) предоставляемого Государственным заказчиком, позволяющего интегрироваться и обмениваться данными с ГЕО ИС.

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

информационное взаимодействие с ГЕО ИС для передачи и получения данных и объектов;

Получение, обработку и представление посредством веб-сервисов картографических данных ГЕО ИС

[Требования по интеграции с <наименование АИС-3>…]

4.1.1.4 Требования к режимам функционирования системы[Режимы определяют порядок эксплуатации и обслуживания системы, что в свою

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

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

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

реконфигурации и пополнения технических и программных средств Системы новыми компонентами;

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

режим работы: доступность функций системы в режиме — 24 часа в день, 7 дней в неделю (24х7). Круглосуточный режим работы системы не требует организации круглосуточной работы пользователей и допускает работу пользователей в соответствии со штатным расписанием.

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

техническое обслуживание;


модернизацию аппаратно-программного комплекса; устранение аварийных ситуаций.

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

4.1.1.5 Требования по диагностированию системы[Требования к диагностированию определяют наличие в системе встроенных средств

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

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

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

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

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

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

прохождения транзакций и т.п.).

4.1.1.6 Перспективы развития, модернизации системы[Требования к развитию могут содержать краткие сведения о целевой архитектуре

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

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

Перспективы развития, модернизации системы и выполнения работ должны коррелировать с показателями назначения (п. 4.1.3 . Показатели назначения)

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

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

Число пользователей …; Объем хранимой информации … .]


4.1.2 Требования к численности и квалификации персонала системы и режиму его работы, требования к квалификации пользователей системы и режиму их работы[В подразделе должны быть указаны:1) требования к численности персонала Системы:2) требования к квалификации персонала Системы, порядку его подготовки и

контроля знаний и навыков;3) требуемый режим работы персонала Системы.4) требования к квалификации пользователей системы5) требуемый режим работы пользователей Системы

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

4.1.2.1 Требования к численности персонала СистемыСтруктура и конфигурация Системы должны быть спроектированы и реализованы с

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

администратор информационной безопасности; администратор системы; администратор баз данных.

[Ненужное зачеркнуть/нужное добавить. Также приводятся требования по численности по всем категориям персонала. Если обслуживающий персонал подразделяется на должности, то необходимо уточнить, в чем различия функций этих должностей.]

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

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

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

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

и серверов баз данных.Уровень квалификации персонала должен соответствовать требованиям

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

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

настройка и мониторинг работоспособности средств защиты информации; контроль доступа к информационным ресурсам Системы; контроль доступа к сетевым ресурсам.

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


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

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

После подготовки персонала и пользователей проводится контроль знаний и навыков по работе с Системой и составляется Отчет о подготовке персонала и пользователей.

Для подготовки дополнительного персонала и пользователей системы (по завершении работ по государственному контракту) Исполнитель должен подготовить обучающие материалы, включающие курсы для дистанционного обучения в соответствии с требованиями, предъявляемыми Заказчиком

4.1.2.3 Требуемый режим работы персонала Системы[Если явно не указаны расхождения, то предполагается, что режим работы персонала

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

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

4.1.2.4 Требования к квалификации пользователей системы[Ниже приводится пример описания требований к квалификации пользователей,

который может быть использован при наполнении данного раздела. Данный пример должен быть отредактирован в соответствии с реально выполняемыми пользователями функциями.]

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

операционными системами (клавиатура, мышь, управление окнами и приложениями, файловая система);

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

знание основ информационной безопасности.

4.1.2.5 Требуемый режим работы пользователей Системы[Если явно не указаны расхождения, то предполагается, что режим работы

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

4.1.3 Показатели назначения[В подразделе приводят значения параметров, характеризующие степень

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

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


4.1.3.1 Количество пользователей[В подразделе приводят значения по показателям, связанным с количеством

пользователей Системы. Должно быть приведено расчетное и максимальное количество пользователей Системы.]

К показателям количества пользователей относятся:1. расчетное количество пользователей;2. расчетное количество одновременно работающих пользователей;3. максимальное количество пользователей;4. максимальное количество одновременно работающих пользователей.

Пояснения по показателям, связанным с количеством пользователей, приведены в таблице ниже (см. Таблица 9).

Таблица 1 — Определения показателей, связанных с количеством пользователей в Системе

№ Показатель Определение1. Расчетное количество

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

2. Расчетное количество одновременно работающих пользователей

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

3. Максимальное количество пользователей

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

4. Максимальное количество одновременно работающих пользователей

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

Значения показателей количества пользователей, достижение которых необходимо обеспечить, представлено в таблице ниже (см. Таблица 2).

Таблица 2 — Значения показателей количества пользователей

№ Показатель Значение1. Расчетное количество пользователей 2. Расчетное количество одновременно работающих пользователей3. Максимальное количество пользователей 4. Максимальное количество одновременно работающих пользователей

4.1.3.2 Число обрабатываемых объектов[В подразделе приводят значения по показателям, связанным с количеством

обрабатываемых объектов в Системе. Должно быть представлено расчетное и максимальное число обрабатываемых объектов.

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


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

2. расчетное количество основных объектов предметной области обрабатываемых за год (по каждому типу обрабатываемого объекта);

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

4. максимальное количество основных объектов предметной области обрабатываемых за год (по каждому типу обрабатываемого объекта).]

Перечень объектов, в отношении которых применяется данный показатель, приведен в таблице ниже (см. Таблица 3).

Таблица 3 — Перечень типов объектов, в отношении которых применяется показатель

№ Объект Краткое описание1.2.3.

Пояснения по показателям, связанным с количеством объектов в Системе, приведены в таблице ниже (см. Таблица 4).

Таблица 4 — Определения показателей, связанных с числом обрабатываемых Объектов

№ Показатель Определение1. Расчетное количество основных

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

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

2. Максимальное количество основных объектов предметной области обрабатываемых за час (по каждому типу обрабатываемого объекта);

Максимальное количество основных объектов предметной области, обработку которых должна обеспечить архитектура приложения в течение часа

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

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

4. Максимальное количество основных объектов предметной области обрабатываемых за год (по каждому типу обрабатываемого объекта).

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

Значения показателей количества объектов Системы, достижение которых необходимо обеспечить, представлено в таблице ниже (см. Таблица 5).

Таблица 5 — Значения показателей числа обрабатываемых Объектов

№ Объект Количество объектов предметной области, обрабатываемых системой

Расчетное Максимальное


За час За год За час За год2.

3.4.

4.1.3.3 Пропускная способность[В подразделе приводят значения по показателям, связанным с пропускной

способностью Системы.]

К показателям пропускной способности относятся:1. расчетное количество сообщений за час (по каждому информационному

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

потоку);

Пояснения по показателям, связанным с пропускной способностью Системы, приведены в таблице ниже (см. Таблица 6Таблица 6 — Определения показателей, связанныхс пропускной способностью ).

Таблица 6 — Определения показателей, связанных с пропускной способностью

№ Показатель Определение1. Расчетное количество сообщений за

час (по каждому информационному потоку)

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

2. Максимальное количество сообщений за час (по каждому информационному потоку)

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

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

Таблица 7 — Значения показателей пропускной способности Системы № Наименование

информационного потока

Тип передаваемого объекта

Количество сообщений за часРасч. Макс.

1.

2.

3.

4.1.3.4 Время получения отчетности[В подразделе приводят значения по показателям, связанным с временем получения

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


4.1.3.4.1 Время получения отчетности с заранее определенной структурой

К показателям времени получения отчетности с заранее определенной структурой относятся:

1. расчетное время получения отчета с заранее определенной структурой (по каждому отчету);

2. максимальное время получения отчета с заранее определенной структурой (по каждому отчету).

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

Таблица 8 — Определения показателей, связанных с получением отчетности с заранее определенной структурой

№ Показатель Определение1. Расчетное время получения

отчета с заранее определенной структурой (сек)

Время получения отчета с заранее определенной структурой к моменту сдачи результатов работ с учетом удовлетворения всех показателей назначения

2. Максимальное время получения отчета с заранее определенной структурой (сек)

Максимально допустимое время получения отчета с заранее определенной структурой

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

Таблица 9 — Значения показателей получения отчетности с заранее определенной структурой

№ Наименование отчета Расчетное время получения отчета с заранее определенной структурой (сек)

Максимальное время получения отчета с заранее определенной структурой (сек)

1. Количество поступивших заявок

2 5

2. Количество выданных разрешений

5 10

3.

4.1.3.4.2 Время получения отчетности по требованиюК показателям времени получения отчетности «по требованию» относятся:

1. расчетное время получения отчета «по требованию» (по каждому отчету);2. максимальное время получения отчета «по требованию» (по каждому отчету).

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

Таблица 10 — Определения показателей, связанных с получением отчетности по требованию

№ Показатель Определение


1. Расчетное время получения отчета «по требованию» (сек)

Время получения отчета «по требованию» к моменту сдачи результатов работ с учетом удовлетворения всех показателей назначения

2. Максимальное время получения отчета «по требованию» (сек)

Максимально допустимое время получения отчета «по требованию»

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

Таблица 11 — Значения показателей получения отчетности по требованию

№ Наименование отчета Расчетное время получения отчета «по требованию» (сек)

Максимальное время получения отчета «по требованию» (сек)

1. Отчет по поступившим заявкам

2 5

2. Отчет по выданным разрешениям

5 10

3.

4.1.4 Требования к надежности[В требования к надежности должны быть включены состав и количественные

значения показателей доступности/надежности для системы в целом или ее подсистем]

4.1.4.1 Показатели доступности/надежностиК показателям доступности/надежности относятся:

1. доступность;2. надежность;3. время сохранности данных;4. время восстановления после сбоя.

Пояснения по показателям, связанным с доступностью/надежностью, приведены в таблице ниже (см. Таблица 12).

Таблица 12 — Определения показателей, связанных с доступностью/надежностью

№ Показатель Определение1. Надежность, измеряется

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

2. Доступность, измеряется в процентах

Доступность - способность Системы выполнять согласованною функцию в течении оговоренного времени ((время работы ИС - время простоя)/время работы ИС * 100).

3. Время сохранности данных (Recovery Point Objective - RPO), измеряется в часах

Время сохранности данных - допустимый период времени, за который могут быть утрачены данные


4. Время восстановления после сбоя (Recovery Time Objective - RTO) , измеряется в часах

Время восстановления после сбоя - допустимое время восстановления работоспособности

Значения показателей доступности/надежности, достижение которых необходимо обеспечить, представлено в таблице ниже (см. Таблица 13)

Таблица 13 — Значения показателей доступности/надежности

№ Показатель Значение1. Надежность, измеряется

в часах5000 часов

2. Доступность, измеряется в процентах

99,5%

3. Время сохранности данных (Recovery Point Objective - RPO), измеряется в часах

12 часов

4. Время восстановления после сбоя (Recovery Time Objective - RTO) , измеряется в часах

4 часа

4.1.4.2 Требования к программным мероприятиям по обеспечению надежности

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

4.1.5 Требования к безопасности[С учетом размещения серверной части оборудования системы в региональном ЦОД,

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

4.1.6 Требования к эргономике и технической эстетике[В подразделе должны быть указаны показатели Системы, задающие необходимое

качество взаимодействия человека с машиной и комфортность условий работы персонала и пользователей.]

Автоматизированные рабочие места персонала, использующего АС КПР в своей деятельности, должны оборудоваться в соответствии с Санитарными Правилами и Нормами 2.2.2. 542-96 — "Гигиенические требования к видеодисплейным терминалам, персональным электронно-вычислительным машинам и организации работ".

В качестве нормативно-технической документации при эргономическом проектировании компонентов интерфейса Системы должны использоваться государственные стандарты (в том числе стандарты серии ССЭТО — системы стандартов эргономических требований и эргономического обеспечения) и международные стандарты серии ISO 9241-12-98. «Эргономические требования по работе в офисе с терминалами визуального отображения информации».


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

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

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

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

Система должна оборудоваться в соответствии с Санитарными правилами и нормами — СанПиН 2.2.2.542-96 — «Гигиенические требования к видеодисплейным терминалам, персональным электронно-вычислительным машинам и организации работ» (утверждёнными постановлением Госкомсанэпиднадзора РФ от 14 июля 1996 г. № 14).

4.1.7 Требования к транспортабельности для подвижных АС[В подразделе, при необходимости, должны быть приведены конструктивные

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

4.1.8 Требования к эксплуатации, техническому обслуживанию, ремонту и хранению компонентов системы[С учетом размещения серверной части оборудования системы в ЦОД, в данном

подразделе должны быть сформулированы следующие требования:1) Виды и периодичность обслуживания ТС системы или допустимость работы без

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

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

запасных изделий и приборов.4) Особые требования к регламенту обслуживания.]

4.1.8.1 Условия и регламент (режим) промышленной эксплуатацииДолжно быть предусмотрено техническое обслуживание Системы.Требования к срокам и периодичности проведения работ по техническому

обслуживанию для системы в целом и для каждой из подсистем определяются в ЧТЗ на создание составных частей Системы.


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

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

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

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

4.1.8.4 Требования к регламенту обслуживанияПри промышленной эксплуатации Системы входящее в ее состав системное

программное и аппаратное обеспечение должно соответствовать рекомендациям производителя.

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

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

В частности, в обслуживание входят работы: по сохранению (копированию) журналов изменений баз данных и резервных

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

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

комплекса. При этом резервное копирование информации может осуществляться в двух режимах:

создание полной копии базы данных; сохранение изменений, внесенных со времени создания последней архивной

копии (архивные копии log-файлов).Периодичность и очередность этих операций определяются политикой резервного

копирования информации площадкой размещения.Создание полной копии базы данных осуществляется полным копированием всех

файлов указанной базы на внешние носители. При сохранении изменений, внесенных со времени создания последней архивной

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

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

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


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

Должно поддерживаться функционирование эталонной и промышленной платформ Системы.

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

На эталонной платформе Системы не должна вестись разработка. Эталонная платформа Системы должна быть предназначена только для тестирования функциональных возможностей и тестирования обновлений версий.

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

4.1.9 Требования к защите информации от несанкционированного доступа[Если ТЗ — на создание Системы, должна использоваться следующая вставка].Система должна соответствовать действующим в Российской Федерации

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

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

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

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

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

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

[Если ТЗ на модернизацию Системы, должна использоваться следующая типовая вставка].

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


1. Оценить влияние модернизируемых подсистем на уровень информационной безопасности Системы в целом;

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

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

4.1.9.1 Технические требования по защите информации[Если ТЗ — на создание Системы, должна использоваться следующая типовая

вставка]В Техническом проекте должны быть определены и отражены требования и решения

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

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

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

внешними информационными системами; обеспечения конфиденциальности и целостности передаваемой/принимаемой

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

ее компонентов.Должна быть обеспечена возможность защиты информации в Системе от потери и

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

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

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

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

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


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

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

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

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

и обрабатываемые в автоматическом режиме; сведения о произошедших ошибках в системе или процессе предоставления

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

информации.В отношении средств защиты информации, разрабатываемых Исполнителем в

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

При разработке программного кода Исполнитель должен применять методы безопасного программирования, включающие:

ручную и автоматизированную проверку кода на предмет НДВ; использование при разработке доверенной аппаратной платформы с функциями

защиты от НДВ на системном и прикладном уровне; контроль версионности исходного кода; тестирование информационной системы на проникновения (пинтесты).

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

[Если ТЗ — на модернизацию Системы, должна использоваться следующая типовая вставка]

При разработке программного кода Исполнитель должен применять методы безопасного программирования, включающие:

ручную и автоматизированную проверку кода на предмет НДВ; использование при разработке доверенной аппаратной платформы с функциями

защиты от НДВ на системном и прикладном уровне; контроль версионности исходного кода; тестирование информационной системы на проникновения (пинтесты).

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


4.1.10 Требования по сохранности информации при аварияхСохранность информации в Системе должна обеспечиваться: при разрушении данных при механических и электронных сбоях и отказах в

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

Для обеспечения сохранности информации в Системе должны быть включены следующие функции:

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

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

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

4.1.10.1 Перечень событий, при которых должна быть обеспечена сохранность информации в системе

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

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

редактирования/обновления информации.В Системе должна предусматриваться возможность ручного восстановления

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

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

штатное и аварийное отключение электропитания серверной части; штатная перезагрузка Системы и загрузка после отключения; программный сбой общесистемного программного обеспечения, приведший к

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

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

накопителей — после замены компонента и восстановления конфигурации общесистемного программного обеспечения;

аварийная перезагрузка системы, приведшая к нефатальному нарушению целостности файловой системы — после восстановления файловой системы.

4.1.10.2 Требования к регламентам и объемам резервного копирования и архивирования данных

[C учетом размещения серверной части оборудования системы в региональном ЦОД, в данном разделе приводятся особые требования к регламентам и объемам резервного копирования и архивирования данных в случае их наличия]


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

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

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

4.1.11.1 Перечень стран, в отношении которых должна быть обеспечена патентная чистота системы и ее частей

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

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

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

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

4.1.11.2 Требования к использованию лицензионного программного обеспечения

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

4.1.12 Требования по стандартизации и унификации[В требования по стандартизации и унификации должны быть включены показатели,

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


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

Экранные формы должны проектироваться с учетом требований унификации: все экранные формы пользовательского интерфейса должны быть выполнены в

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

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

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

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

[В случае, если работа в создаваемой системе организованная по средствам веб-интерфейса, необходимо указать совместимость с браузерами и мобильными устройствами, при необходимости]

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

Internet Explorer, версия 7 и выше; Mozilla Firefox, версия 3.0 и выше; Opera, версия 10 и выше; Google Chrome, версия 0.2.149 и выше; Apple Safari, версия 3.0 и выше.

Также, Система должна корректно работать и полностью сохраняться весь функционал на мобильных устройствах (мобильные телефоны, смартфоны, планшеты).

4.1.13 Дополнительные требования [В дополнительных требованиях должны быть указаны: требования к оснащению системы устройствами для обучения персонала

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

требования к системе, связанные с особыми условиями эксплуатации; Требования по сертификации Системы, ее компонентов специальные требования по усмотрению Исполнителя или Заказчика системы.]

4.1.13.1 Требования к оснащению системы устройствами для обучения персонала и документацией на них

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

4.1.13.2 Требования к Системе, связанные с особыми условиями эксплуатации

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


4.1.13.3 Требования по сертификации Системы, ее компонентовНеобходимо получить свидетельство <наименование свидетельства>.

4.1.13.4 Специальные требования

4.1.14 Требования к электронным учебным курсам[Ниже приводится типовая вставка, которая может быть использована при

наполнении данного раздела. Данная вставка должна быть отредактирована в соответствии с выполняемыми работами. Требуется только в случае необходимости разработки электронных учебных курсов в рамках выполняемых работ]

4.1.14.1 Требования по соответствию электронных курсов международным стандартам

4.1.14.2 Требования к формату используемых в курсе файловК формату используемых в курсе файлов предъявляются следующие требования: возможность вставки в курсы любого Rich-media содержимого: Macromedia®

Flash®, Shockwave®, Java®, видео в форматах (AVI, WMV, MPEG, MOV, RM, FLV); простые механизмы вставки и синхронизации звукового сопровождения в

форматах: AIFF, WMA, MP3, WAV, SWF; Присоединяемые внешние документы могут быть: Текстовый файл (TXT),

HTML файл, Rich Text Format (RTF), Microsoft Word (DOC), Microsoft Excel (XLS), Adobe PDF, Архив ZIP, Архив RAR и т. д.

4.1.14.3 Требования к просмотру электронных курсов через браузерЭлектронные курсы в полном объеме и с полным функциональным наполнением

должны просматриваться в браузерах: Internet Explorer 6.0 и выше, FireFox 3.0, Google Chrome 1 и выше, Opera 11 и выше, Apple Safari 4.0.

4.2 Требования к функциям (задачам), выполняемым системой[В разделе должны быть изложены требования к функциям по каждому элементу,

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

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

4.2.1 Требования к сценариям (процессам), автоматизируемым данной системой … [Данный раздел должен содержать перечень и описание бизнес-сценариев

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


• Каждый бизнес-сценарий описывается в отдельном подразделе• Описание бизнес-сценария должно быть сделано в свободной описательной

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

• При использовании в решении системы класса BPM, для каждого бизнес-сценария, дополнительно к текстовому описанию, должна быть схема моделирования в нотации bpmn 2.0.

• Описание каждого бизнес-сценария должно быть согласовано с функциональным заказчиком.]

4.2.1.1 Сценарий <название сценария>[Подробное описание автоматизируемого бизнес сценарии]

Назначение[Описывается назначение сценария]Режимы запуска[Приводятся условия запуска сценария, требования к участию пользователя, к

готовности данных, привязке к бизнес-событиям и т.д]Основные алгоритмы[Указываются алгоритмы работы сценария (основной сценарий, варианты действий

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

Логирование[Указывается, каким образом будет осуществляться логирование событий, связанных

с работой сценария]Дополнительные требования[Указываются:• Требования к пользовательскому интерфейсу и отчетным формам (при

необходимости)• Дополнительная информация (при необходимости большей детализации

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

Пояснения по показателям назначения сценария приведены в таблице ниже (см. Таблица 14)Таблица 14 — Определение показателей назначения сценария

№ Показатель Определение1. Максимальное

количество обращений к сценарию

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

2. Расчетное время исполнения сценарию

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

3. Максимальное время исполнения сценария.

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


Значения показателей назначения сценария, достижение которых необходимо обеспечить, представлено в таблице ниже (см. Таблица 15)

Таблица 15 — Показатели назначения сценария№ Показатель Значение

1. Максимально возможное использование сценария

1000000

2. Расчетное время исполнения сценария (сек)

0,001

3. Максимальное время исполнения сценария (сек)

0,01

4.2.2 Требования к функциям подсистемы …

4.2.2.1 Требования к функциям модуля …

4.2.2.1.1 Требования к функции …

4.2.3 Требования к АРМ …

4.2.3.1 Требования к форме

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

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

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

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

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

моделей, типовых алгоритмов и алгоритмов, подлежащих разработке.]

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


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

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

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

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

продуцируемым техническими средствами АС (в соответствии с ГОСТ 6.10.4-84). Ниже пример, однако использовать его нужно вдумчиво и дополнять по аналогии там, где недостает необходимых данных].

4.3.2.1 Требования к составу, структуре и способам организации данных в системе

[Информационное обеспечение представляет собой совокупность всех необходимых для функционирования системы данных и систем обеспечения. В состав информационного обеспечения входят:

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

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

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

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

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

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

4.3.2.3 Требования к информационному обмену между компонентами системы

Информационный обмен между компонентами Системы должен осуществляться без вмешательства пользователя и без повторного ручного ввода информации.

Информационный обмен между компонентами Системы и клиентскими приложениями должен осуществляться по локальной сети и по сети Интернет.

Факты информационного обмена должны фиксироваться в соответствующем журнале.


4.3.2.4 Объем и состав информации, получаемой из классификаторовОбъем и состав информации, получаемой из классификаторов, должны быть

определены на этапе предварительного проектирования.

4.3.2.5 Требования к разработке дополнительных классификаторовВ случае выявления возможности использования данных таких справочников

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

4.3.2.6 Требования по применению систем управления базами данныхДля хранения данных в Системе должны использоваться реляционные базы данных,

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

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

Общие требования к используемой реализации СУБД: поддержка реляционной или объектно-реляционной модели базы данных; поддержка технологии клиент-сервер; поддержка многопроцессорной архитектуры; наличие средств создания индексов и кластеров данных; автоматическое восстановление базы данных; совместимость с различными операционными системами серверов БД; поддержка сетевых протоколов TCP/IP; наличие графических средств администрирования; возможность контроля доступа к данным; централизованное управление учетными записями пользователей; оптимизация запросов.

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

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

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

В Системе должна быть обеспечена защита данных от утраты или нарушения целостности в следующих случаях:

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

при авариях, приведших к невозможности восстановления данных с сервера СУБД — использованием процедур резервного копирования баз данных Системы и хранения резервных копий на съемном носителе.

Дополнительные требования к защите данных от разрушений при авариях и сбоях в электропитании Системы не предъявляются.


4.3.2.9 Требования к контролю, хранению, обновлению и восстановлению данных

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

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

4.3.3 Требования к лингвистическому обеспечению[В подразделе должны быть приведены следующие требования: требования к применению в системе языков программирования; требования к применению в системе языков взаимодействия пользователей и

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

Формулировки ниже обычно достаточно.]Все экранные формы, выходные формы, инструкции по работе, вся документация

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

4.3.4 Требования к программному обеспечению[В подразделе должны быть указаны: состав и структура программного обеспечения, включая операционные

системы, СУБД, базовые платформы, используемые библиотеки компонентов и шаблоны;

в случае использования базового ПО должны быть определены и ограничены функции, которые возложены на базовое ПО;

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

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

требования к структуре и форме предъявления дистрибутива специального ПО, разрабатываемого в рамках ТЗ, включая базовую конфигурацию;

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

требования к средствам разработки и/или средствам проектирования прикладного программного обеспечения, а также к порядку управления версиями элементов специального ПО];

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


4.3.5 Требования к техническому обеспечению[C учетом размещения серверной части оборудования системы в региональном ЦОД,

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

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

в явном виде должно быть предъявлено требование, что состав и схема подключения и конфигурации технических средств должны быть приведены в документе «Описание архитектуры системы»,].

4.3.6 Требования к метрологическому обеспечению

4.3.7 Требования к телекоммуникационному обеспечению системы

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

использованием локальной сети и Интернет.

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

использованием локальной сети и Интернет.

4.3.7.3 Технические параметры каналов связиСпециальные требования не предъявляются.

4.3.7.4 Пропускная способность, интерфейсы, топология и т.п.Пропускная способность каналов связи должна быть не ниже 1 Мбит/с.

4.3.7.5 Необходимость организации новых каналов связи.Требования к организации новых каналов не предъявляются.

4.3.8 Требования к другим видам обеспечения


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

5.1 Этапы работ[Далее приведен рекомендуемый перечень стадий и этапов работ, а также их

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

Этапы проведения работ по созданию <название или обозначение АИС> приведены в таблице ниже (см. Таблица 99).

Таблица 9 — Этапы проведения работ по созданию АИС

№ этапа

Наименование и содержание

выполняемых работ

Сроки выполненияОтчетная документация

Начало Конец

1. Этап 1. Проектирование

1.1 Предварительное проектирование

Отчет об обследовании объекта автоматизацииЧТЗ, детализирующее требования [Привести конкретный перечень разрабатываемых ЧТЗ.Может быть одно ЧТЗ на систему в целом, на каждую из подсистем, либо на некоторые подсистемы в случае их модернизации]Описание архитектуры

1.2 Техническое проектирование

Дата утверждения Заказчиком результатов работ Этапа 1.1.

Пояснительная записка к техническому проектуПроект модели угроз с приложением Проекта акта классификации[В случае модернизации – актуализированный Проект модели угроз с приложением Проекта акта классификации]

1.3 Рабочее проектирование Дата утверждения Заказчиком результатов работ Этапа 1.2.

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


№ этапа




Начало КонецРегламент эксплуатации системыРегламент гарантийного обслуживанияПлан восстановления в случае аварииРуководство администратораРуководство пользователяПроекты регламентов взаимодействия[Привести конкретный перечень разрабатываемых Регламентов. Регламент должен разрабатываться для всех внешних взаимодействий.В случае модернизации взаимодействия – актуализированные Регламенты]Комплект документов для постановки ИС на мониторингАкт сдачи-приемки работ по этапуАкт приема-передачи научно-технической продукции по этапу

1.4 Сдача-приемка результатов работ Этапа 1

Подписанные Заказчиком и Исполнителем результаты Этапа 1

2. Этап 2. Предварительные испытания

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

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



3 Этап 3. Опытная


№ этапа




Начало Конецэксплуатация

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

Отчет о проведении опытной эксплуатации с приложением Журнала опытной эксплуатацииАкт о завершении опытной эксплуатации и допуске системы к приемочным испытаниям Отчет о подготовке персонала с приложением Протокола подготовки персоналаПрограмма и методика приемочных испытаний Актуализированное описание архитектурыАкт сдачи-приемки работ по этапуАкт приема-передачи научно-технической продукции по этапуПроект протокола проведения приемочных испытанийПроект акта о готовности системы к промышленной эксплуатацииПроект нормативно-правового акта о вводе системы в промышленную эксплуатациюПроект акта о приемке системы в промышленную эксплуатацию


Подписанные Заказчиком и Исполнителем результаты Этапа 3.

4 Этап 4. Приемочные испытания

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

Протокол проведения приемочных испытанийАкт о готовности системы к промышленной эксплуатацииАкт сдачи-приемки работ по этапуАкт приема-передачи научно-технической продукции по этапу



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


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

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

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


6 Порядок контроля и приемки системы[В разделе должны быть указаны: виды, состав, объем и методы испытаний системы и ее составных частей (виды

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

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

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

6.1 Виды, состав, объем и методы испытаний системы и ее составных частейИспытания должны быть организованы и проведены в соответствии с ГОСТ 34.603-

92 «Информационная технология. Виды испытаний автоматизированных систем».Должны быть проведены следующие виды испытаний: предварительные испытания; опытная эксплуатация (ОЭ); приемочные испытания.

[По усмотрению Заказчика до окончания опытной эксплуатации может быть проведено нагрузочное тестирование, результаты которого отражаются в Акте о завершении опытной эксплуатации.]

Отдельные виды испытаний проводятся поэтапно в сроки, установленные Календарным планом выполнения работ.

До начала этапа «Опытная эксплуатация» Исполнитель передает Заказчику полный набор логинов, паролей и других параметров доступа к Системе, необходимых для ее развертывания и эксплуатации.

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

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

При проведении перечисленных испытаний в части информационного взаимодействия Системы с <наименование АИС, с которым была проведена интеграция> проверяется наличие в Системе и соответствие установленным требованиям сервисов приема/передачи данных. Возможность проверки реального информационного взаимодействия производится в случае предоставления оператором <наименование АИС, с которым была проведена интеграция> данных, определенных соответствующим «Регламентом взаимодействия».

6.2 Общие требования к приемке работ по стадиямПриемка результатов работ осуществляется поэтапно в соответствии с календарным

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

приемки работ. Основанием для составления и подписания Акта сдачи-приемки работ по отдельному этапу является передача Исполнителем результатов работ в соответствии с


условиями Государственного контракта и (при проведении испытаний) утвержденных сторонами соответствующих Актов приемки в эксплуатацию.

Техническая и эксплуатационная документация и другие результаты работ передаются Заказчику в порядке, определенном подразделом «1.10 Порядок оформления и предъявления Заказчику результатов работ». Комплектность передаваемых результатов работ (документации) подлежит проверке Заказчиком.

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

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

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

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

Условием для передачи системы в опытную или промышленную эксплуатацию является устранение всех замечаний с высоким уровнем критичности на уже проведенных испытаниях.

В случае отклонения Системы от требований, предъявляемых на испытаниях, сроки проведения испытаний могут быть перенесены/расширены Заказчиком в пределах сроков выполнения работ в соответствии с Календарным планом.

6.2.1 Порядок сдачи-приемки результатов работ по Этапу 1.

6.2.1.1 Порядок сдачи результатов работ по пункту 1.1. Календарного плана• Не позднее, чем за 10 рабочих дней до окончания работ, указанных в пункте

1.1. Календарного плана, Исполнитель в электронной форме направляет Заказчику результаты работ: Отчет об обследовании объекта автоматизации и ЧТЗ на подсистему(ы), Описание архитектуры.

• Заказчик в течение 5-ти рабочих дней рассматривает представленные результаты и в электронной форме направляет Исполнителю Заключение на результаты работ, указанные в пункте 1.1. Календарного плана.

• Исполнитель в течение 3-х рабочих дней с момента получения Заключения в электронной форме при необходимости дорабатывает результаты работ и направляет их в электронной форме Заказчику.

• Заказчик либо согласовывает результаты работ, указанные в пункте 1.1. Календарного плана, и информирует об этом Исполнителя, либо в течение 10-ти рабочих дней с момента получения результатов работ, указанных в пункте 1.1. Календарного плана, на бумажном носителе направляет в адрес Исполнителя мотивированный отказ в утверждении результатов работ, указанных в пункте 1.1. Календарного плана.


• Работы, указанные в пункте 1.2. Календарного плана, Исполнитель начинает выполнять только на основании согласованных Заказчиком результатов работ, указанных в пункте 1.1.

6.2.1.2 Порядок сдачи результатов работ по пункту 1.2. Календарного плана• Не позднее, чем за 10 рабочих дней до окончания работ, указанных в пункте

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


• Исполнитель в течение 3-х рабочих дней с момента получения Заключения в электронной форме при необходимости дорабатывает результаты работ и представляет их в электронной форме Заказчику.

• Заказчик либо согласовывает результаты работ, указанные в пункте 1.2. Календарного плана, и информирует об этом Исполнителя, либо в течение 10-ти рабочих дней с момента получения результатов работ, указанных в пункте 1.2. Календарного плана, на бумажном носителе направляет в адрес Исполнителя мотивированный отказ в утверждении результатов работ, указанных в пункте 1.2. Календарного плана.

• Работы, указанные в пункте 1.3. Календарного плана, Исполнитель начинает выполнять только на основании согласованных Заказчиком результатов работ, указанных в пункте 1.2.

6.2.1.3 Порядок сдачи результатов работ, указанных в пункте 1.3. Календарного плана

• В день окончания работ, указанных в пункте 1.3. Календарного плана, Исполнитель в электронной форме направляет Заказчику результаты работ: Сопроводительное письмо с предложением по составу приемочной комиссии, Программу и методику предварительных испытаний (с приложением Проекта протокола предварительных испытаний и Проекта акта приемки в опытную эксплуатацию), Ведомость машинных носителей информации, Инструкцию по развертыванию системы в комплекте с дистрибутивами, Паспорт Системы, Регламент эксплуатации системы, Регламент гарантийного обслуживания, План восстановления в случае аварии, Руководство администратора, Руководство пользователя, Проекты регламентов взаимодействия, комплект документов для постановки ИС на мониторинг.


• Исполнитель не позднее, чем за 5-ть рабочих дней до окончания работ по Этапу 1, на основании заключения при необходимости дорабатывает результаты работ и представляет их в бумажной и электронной форме Заказчику, дополнительно приложив к ним Акт сдачи-приемки работ по Этапу 1 и Акт приема-передачи научно-технической продукции по Этапу 1.

• В случае, если все замечания, зафиксированные в заключении по результатам исполнения Этапа 1, были устранены Исполнителем, Заказчик в срок, указанный в пункте 1.4. Календарного плана, принимает и утверждает результаты работ по Этапу 1 путем


подписания Акта сдачи-приемки работ по Этапу 1, и Акта приема-передачи научно-технической продукции по Этапу 1 и всех результатов работ по Этапу 1.

• В случае, если какие-либо замечания, зафиксированные в заключении по результатам исполнения Этапа 1, не были устранены Исполнителем, Заказчик в течение 10-ти рабочих дней с момента получения на бумажном носителе результатов работ, указанных в пункте 1.3. Календарного плана, вправе направить в адрес Исполнителя мотивированный отказ в приемке и утверждении результатов работ по Этапу 1.

6.2.2 Порядок сдачи-приемки результатов работ по Этапу 2• Не позднее срока, указанного в пункте 2.1. Календарного плана, Исполнитель в

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


• Исполнитель не позднее, чем за 5-ть рабочих дней до даты начала работ, указанных в пункте 2.2. Календарного плана, при необходимости дорабатывает документы и проекты документов по Этапу 2 и в электронном виде направляет Заказчику, дополнительно приложив к ним Акт сдачи-приемки работ по Этапу 2 и Акт приема-передачи научно-технической продукции по Этапу 2. Документы в бумажной форме предоставляются Исполнителем Заказчику на предварительных испытаниях.

• Не позднее, чем за 2 рабочих дня до даты начала работ, указанных в пункте 2.2. Календарного плана, в случае, если Исполнителем в электронном виде представлены документы, предусмотренные пунктом 2.1. Календарного плана, в полном объеме и надлежащего качества, Заказчик выпускает распорядительный документ о составе приемочной комиссии, дате и месте проведения испытаний, копию которого в электронной форме направляет Исполнителю.

• В период времени, предусмотренный пунктом 2.2. Календарного плана, в дату и месте, предусмотренные распорядительным документом Заказчика о составе приемочной комиссии, дате и месте проведения испытаний, приемочной комиссией, в состав которой входят представители Заказчика и Исполнителя, проводятся предварительные испытания системы.

• На предварительных испытаниях представителем Исполнителя в электронной форме ведется Протокол предварительных испытаний. Протокол предварительных испытаний подписывается приемочной комиссией, утвержденной распоряжением Заказчика о составе приемочной комиссии, дате и месте проведения испытаний, и передается Заказчику вместе с актом приемки в опытную эксплуатацию и актом сдачи-приемки работ по этапу на бумажном носителе не позднее, чем за 5-ть рабочих дней до окончания Этапа 2.

• Заказчик, в случае отсутствия каких-либо замечаний, в срок, указанный в пункте 2.2. Календарного плана, утверждает результаты работ по Этапу 2 путем подписания Акта сдачи-приемки работ по Этапу 2 и Акта приема-передачи научно-технической продукции по этапу 2.

6.2.3 Порядок сдачи-приемки результатов работ по Этапу 3• Не позднее срока, указанного в пункте 3.1. Календарного плана, Исполнитель в

электронной форме направляет Заказчику документы: Отчет о проведении опытной эксплуатации с приложением Журнала опытной эксплуатации, Акт о завершении опытной


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


• Исполнитель не позднее, чем за 5-ть рабочих дней до окончания работ по Этапу 3, на основании Экспертного заключения при необходимости дорабатывает документы по Этапу 3 и представляет их в бумажной и электронной форме Заказчику, дополнительно приложив к ним Акт сдачи-приемки работ по Этапу 3 и Акт приема-передачи научно-технической продукции по Этапу 3.

• В случае, если все замечания, зафиксированные в Экспертном заключении по результатам исполнения Этапа 3, были устранены Исполнителем, Заказчик в срок, указанный в пункте 3.2. Календарного плана, утверждает результаты работ по Этапу 3 путем подписания Акта сдачи-приемки работ по Этапу 3 и Акта приема-передачи научно-технической продукции по этапу 3.

• В случае, если какие-либо замечания, зафиксированные в Экспертном заключении по результатам исполнения Этапа 3, не были устранены Исполнителем, Заказчик в течение 10-ти рабочих дней с момента получения результатов работ по Этапу 3 на бумажном носителе вправе направить в адрес Исполнителя мотивированный отказ в утверждении результатов работ по Этапу 3.

6.2.4 Порядок сдачи-приемки результатов работ по Этапу 4.• Не позднее, чем за 2 рабочих дня до даты начала работ, указанных в пункте 4.1.

Календарного плана Заказчик выпускает распорядительный документ о составе приемочной комиссии, дате и месте проведения испытаний, копию которого в электронной форме направляет Исполнителю.

• В период времени, предусмотренный пунктом 4.1. Календарного плана, в дату и месте, предусмотренные распорядительным документом Заказчика о составе приемочной комиссии, дате и месте проведения испытаний, приемочной комиссией, в состав которой входят представители Заказчика и Исполнителя, проводятся приемочные испытания системы.

• На приемочных испытаниях представителем Исполнителя в электронной форме ведется Протокол приемочных испытаний. Протокол приемочных испытаний подписывается приемочной комиссией, утвержденной распоряжением Заказчика о составе приемочной комиссии, дате и месте проведения испытаний, и передается Заказчику вместе с Актом о готовности системы к промышленной эксплуатации, Актом сдачи-приемки работ по этапу 4, Актом приема-передачи научно-технической продукции по этапу 4 на бумажном носителе не позднее, чем за 5-ть рабочих дней до окончания Этапа 4.

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


6.3 Сведения о гарантийном обслуживании системыГарантийное обслуживание проводится в сроки, определенные Государственным

контрактом.Исполнитель должен гарантировать, что модернизированное и разработанное

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

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

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

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

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

6.4 Порядок выполнения доработок и устранения допущенных Исполнителем ошибок, которые выявлены в процессе испытаний и в период гарантийного обслуживанияНедостатки и ошибки в реализации Системы, выявленные в ходе проведения

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

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

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

6.5 Статус приемочной комиссии

6.6 Сведения об обслуживании системыСостав работ по эксплуатации Системы, а также их периодичность и требования к

составу и квалификации обслуживающего персонала, определяются в эксплуатационной


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

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


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

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

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

Кто и как должен загрузить исходные данные, справочники, исторические данные?

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

Кто и как должен разработать и утвердить нормативную документацию? Кто и как должен подготовить пользователей и организовать эксплуатацию

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

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

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

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

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

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

7.1 Развертывание и конфигурированиеСистема должна быть установлена Исполнителем на оборудовании,

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

Дальнейшее конфигурирование должно быть выполнено Исполнителем (сервисным оператором) в соответствии с инструкцией по развертыванию системы, приведенной в руководстве Администратора.

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

7.2 Приведение поступающей в систему информации к виду, пригодному для обработки с помощью ЭВМДля приведения поступающей в Систему информации к виду, пригодному для

обработки с помощью ЭВМ, должны быть проведены системно-аналитические мероприятия


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

Должны быть описаны и утверждены вновь вводимые справочники и классификаторы.

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

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

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

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

7.3.1 Создание условий функционирования объекта автоматизации, при которых гарантируется соответствие создаваемой системы требованиям[Здесь описываются действия, которые должны быть обеспечены Исполнителем: Разработка проектов нормативно-правовой документации. Организация выделения телематических ресурсов в случае необходимости

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

Изменение конфигурации внешних систем, с которыми взаимодействует Система.

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

7.3.2 Создание необходимых для функционирования системы подразделений и службДополнительный перечень мероприятий, который необходимо осуществить в

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

7.3.3 Сроки и порядок комплектования штатов и обучения персоналаКомплектование штатов и подразделений, необходимых для функционирования

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

Обучение персонала должно проводиться Исполнителем по разработанным руководствам и документу «План-программа подготовки персонала (с приложением формы Отчета о подготовке персонала)».

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

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


8 Требования к документированию[В разделе должны быть приведены: согласованный Разработчиком и Заказчиком Системы перечень подлежащих

разработке комплектов и видов документов, соответствующих требованиям ГОСТ 34.201-89 и НТД отрасли Заказчика;

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

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

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

ГОСТ 34.003-90 — в части терминологии; ГОСТ 34.201-89, ГОСТ 19.101-77-82, 19.103-77 — в части наименования и

обозначения документов; ГОСТ 34.601-90 — в части определения стадий и этапов работ; ГОСТ 34.602-89 — в части состава, содержания и правил оформления

документов «Техническое задание», «Частное техническое задание». ГОСТ 34.603 -92 — в части определения видов испытаний; РД 50-34.698-90 — в части структуры и содержания документов; ГОСТ 7.32-2001 — в части структуры и правил оформления отчета о

проведении информационно-аналитического обследования.Документы на Систему должны оформляться в соответствии с требованиями

ГОСТ 2.105-95 на листах формата А4 по ГОСТ 2.301-68 без рамки, основной надписи и дополнительных граф к ней. Допускается для размещения рисунков и таблиц использование листов формата А3 с подшивкой по короткой стороне листа. Документы объемом более 25 листов должны содержать информационную часть, состоящую из аннотации и содержания.

Разработанная документация должна представляться Исполнителем в двух экземплярах на бумажном и электронном носителях.

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

Комплект эксплуатационной документации на Систему должен содержать сведения, достаточные для эксплуатации Системы в соответствии с <указать Положение или другой НПА, если таковой имеется>, а также:

в части ПО Системы должен содержать исчерпывающее описание ПО по ГОСТ 19.ХХХ, обеспечивающее его установку, настройку, эксплуатацию и сопровождение;

в части комплекса технических средств (КТС) Системы должен содержать исчерпывающее описание КТС по ГОСТ 34.ХХХ, обеспечивающее развертывание ПО Системы, а также сопровождение КТС ИС.

Формальное полное соответствие документов на Систему требованиям РД 50-34.698-90 и ГОСТ 19.ХХХ по составу и структуре разделов не требуется. При этом должно быть достигнуто адекватное описание всех видов обеспечения АИС, достаточное для подготовки персонала, развертывания, эксплуатации и сопровождения АИС по всем позициям, определяемым РД 50-34.698-90 и ГОСТ 19.ХХХ для отдельных документов.

Документам на Систему должны в обязательном порядке присваиваться уникальные децимальные номера в соответствии с порядком, установленном в ГОСТ 34.201-89, ГОСТ 19.101-77-82, ГОСТ 19.103-77.


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

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

До начала стадии «Приемочные испытания» Исполнитель передает Заказчику полный набор логинов, паролей и других параметров доступа к Системе, необходимых для ее развертывания и эксплуатации. Указанные сведения должны включаться в документ «Руководство администратора»;

Документы «Руководство пользователя», «Руководство администратора» и другие документы, регламентирующие деятельность персонала, должны содержать описание выполнения операций (действий) персонала в технологическом процессе Пользователя Системы, т.е. описание должно строиться на основе технологических задач персонала с использованием возможностей Системы и не должно сводиться к простому описанию (перечислению) функций Системы. При этом в указанных документах должна быть отражена работа всех функций по подсистемам, определенным в подразделе 4.2. Указанные документы должны содержать описание выполнения операций (действий) всех категорий персонала, определенных в ТЗ и другой документации на Систему;

Контроль качества эксплуатационной документации должен производиться с использованием методик и критериев, определенных для документации программных средств следующими государственными стандартами и руководящими документами по стандартизации: класс стандартов ГОСТ 19, класс стандартов ГОСТ 34, РД 50-34.698-90, ГОСТ 28195-89, ГОСТ 28806-90, ГОСТ 16504-81, ГОСТ Р ИСО/МЭК ТО 12182-2002, ГОСТ Р ИСО/МЭК 12207:1999, ГОСТ Р ИСО/МЭК ТО 15271-2002, ГОСТ Р ИСО/МЭК 9126:93, ГОСТ Р ИСО/МЭК 15026:1998, ГОСТ Р ИСО/МЭК 14764:2002, ГОСТ Р ИСО/МЭК ТО 9294:93, ГОСТ Р ИСО/МЭК 15910-2002, ISO 14756: 1999, ГОСТ 2.051-2006.

Документ «Регламент взаимодействия» (далее — Регламент) должен содержать разделы:

Общая часть: Назначение, основание разработки и применения, область применения; Объекты регулирования Регламента: определение субъектов, объектов и

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

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

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

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

0 Ведение осуществляется в соответствии с постановлением Правительства Сахалинской

области от 30.06.2013 г. № 286 «Об учете информационных систем и компонентов

информационно-телекоммуникационной инфраструктуры Сахалинской области»


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

Документ «Описание архитектуры» должен содержать следующие разделы: компоненты системы; прикладная архитектура; информационное взаимодействие; технологический дизайн; дизайн размещения на аппаратных средствах; политика резервного копирования; предлагаемое системное программное обеспечение.

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

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

приложениями.Уровень презентаций должен быть разработан в соответствии с принципами

архитектуры «тонкого клиента».

Документ «План восстановления в случае аварии» должен содержать следующие разделы:

описание стратегии восстановления (высокоуровневый план по достижению показателей RTO/RPO. Описание методов, обеспечивающих оперативное восстановление работоспособности компонентов и ИС в целом);

описание разработанных отказоустойчивых решений (описание отказоустойчивого решения, удовлетворяющего показателям RTO/RPO (высокая доступность, резервное копирование), определение превентивных защитных мер (снижение рисков нарушения работы ИС или производительности));

описание регламента тестирования плана аварийного восстановления (мероприятия по проведению учений, тестовые восстановления);

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

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

С учетом того, что АИС Сахалинской области размещаются в ЦОД, план аварийного восстановления не должен касаться следующих подсистем ЦОД:

1. Инженерные подсистемыa. Система бесперебойного энергоснабжения, ИБПb. Система гарантированного энергоснабжения, ДГУc. Система кондиционирования и вентиляции воздухаd. Структурированная кабельная система (СКС)e. Комплекс интегрированных технических средств безопасности:

i. Система видео наблюденияii. Система охранной сигнализации помещения

iii. Система контроля и управления доступом (СКУД)iv. Система пожарной безопасности помещения (пожарная сигнализация и

пожаротушение).v. Система мониторинга и управления инженерным оборудованием

2. Вычислительная инфраструктура


a. Сервераb. Подсистема виртуализации

3. Системы хранения данныхa. Дисковые и ленточные системы хранения данных

4. Сети передачи данных5. Системы управления и мониторинга

Дополнительные требования к составу, структуре и содержанию документов (кроме приведенных выше и отличные от содержащихся в указанных в данном разделе ГОСТ) должны быть подготовлены Государственным заказчиком и переданы Исполнителю на стадии технического проектирования (раздел 5). Дополнительные требования оформляются протоколом или дополнением к данному ТЗ. Дополнение или указанный протокол являются неотъемлемой частью ТЗ и должны быть утверждены в установленном порядке.>


9 Источники разработки[В разделе должны быть перечислены документы и информационные материалы

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

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

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

9.3 Нормативно-правовые актыВ настоящем документе использованы следующие нормативно-правовые акты:1) Постановление Сахалинской области от 24 мая 2011 года № 191 «О системе

межведомственного электронного взаимодействия Сахалинской области»;2) Федеральный закон от 22 октября 2004 года № 125-ФЗ «Об архивном деле в

Российской Федерации »;3) Федеральный закон от 27 июля 2006 года № 152-ФЗ «О персональных данных»;4) Федерального закона от 27 июля 2010 года № 210-ФЗ «Об организации

предоставления государственных и муниципальных услуг»;5) Федеральный закон от 21 июля 2005 № 94-ФЗ «О размещении заказов на

поставки товаров, выполнение работ, оказание услуг для государственных и муниципальных нужд» (в редакции от 30 декабря 2012 г. № 318-ФЗ);

6) Приказ ФСТЭК России от 11 февраля 2013 г. № 17 «Об утверждении требований о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах».

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

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

конфиденциальной информации (СТР-К)», утвержденный приказом Гостехкомиссии России от 30.08.2002 г. № 282.

9.5 Нормативно-технические документыВ настоящем документе использованы следующие нормативно-технические

документы:1) Единая система программной документации (класс стандартов ГОСТ 19);2) Информационная технология. Комплекс стандартов на автоматизированные

системы (класс стандартов ГОСТ 34);3) РД 50-34.698-90. Методические указания. Информационная технология.

Автоматизированные системы. Требования к содержанию документов;4) ГОСТ 28195-89. Оценка качества программных средств. Общие положения;


5) ГОСТ 28806-90. Качество программных средств. Термины и определения;6) ГОСТ 16504-81. Система государственных испытаний продукции. Испытания и

контроль качества продукции. Термины и определения;7) ГОСТ Р ИСО/МЭК ТО 12182-2002. Информационная технология.

Классификация программных средств;8) ГОСТ Р ИСО/МЭК 12207:1999. Процессы жизненного цикла программных

средств;9) ГОСТ Р ИСО/МЭК ТО 15271-2002. Информационная технология. Руководство

по применению ГОСТ Р ИСО/МЭК 12207;10) ГОСТ Р ИСО/МЭК 9126:93. Информационная технология. Оценка программной

продукции. Характеристики качества и руководства по их применению;11) ГОСТ Р ИСО/МЭК 15026:1998. Информационная технология. Уровни

целостности систем и программных средств;12) ГОСТ Р ИСО/МЭК 14764:2002. Информационная технология. Сопровождение;13) ГОСТ Р ИСО/МЭК ТО 9294:93. Информационная технология. Руководство по

управлению документированием программного обеспечения;14) ГОСТ Р ИСО/МЭК 15910-2002. Информационная технология. Процесс создания

документации пользователя программного средства;15) ISO 14756: 1999. ИТ. Измерение и оценивание производительности

программных средств компьютерных вычислительных систем;16) ГОСТ 2.051-2006. Единая система конструкторской документации. Электронные

документы. Общие положения;17) ГОСТ 7.32-2001 «Отчет о научно-исследовательской работе. Структура и

правила оформления»;18) ГОСТ 15.012-84. «Патентный формуляр»;19) ГОСТ 19.101.77 «Виды программ и программных продуктов»;20) ГОСТ 2.105-95. «Единая система конструкторской документации. Общие

требования к текстовым документам»;21) «Российский коммуникативный формат представления библиографических

записей. Книги и сериальные издания» 1998 г;22) ГОСТ 21552-84 «Средства вычислительной техники. Общие технические

требования, приемка, методы испытаний, маркировка, упаковка, транспортировка, хранение»;

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

24) ГОСТ 6.10.4-84. Унифицированные системы документации. Придание юридической силы документам на машинном носителе и машинограмме, создаваемым средствами вычислительной техники. Основные положения;

25) ГОСТ 34.003-90. Информационная технология. Комплекс стандартов на автоматизированные системы. Термины и определения;

26) ГОСТ 34.601-90. Автоматизированные системы. Стадии создания;27) ГОСТ 34.603-92. Информационная технология. Виды испытаний

автоматизированных систем;28) СанПиН 2.2.24.548-96. Физические факторы производственной среды.

Гигиенические требования к микроклимату производственных помещений;29) СанПиН 2.2.2/2.4.1340-03. Гигиенические требования к персональным

электронно-вычислительным машинам и организации работ.


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

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


Documents

cit.sakhalin.gov.ru · Web view4.1.9.1 Технические требования по защите информации29 4.1.10 Требования по сохранности