4.1.3.Показатели назначения
Ключевым показателем назначения Подсистемы является выполнение заложенных функций (задач), перечисленных в разделе 4.2 настоящего документа.
Подсистема должна обеспечить обработку не менее 200 транзакций/запросов в секунду.
При этом максимальное время обработки транзакций/запросов не должно превышать 5 секунд.
Определение размера и динамики увеличения числа транзакций/запросов является предметом работ по-настоящему ТЗ.
Подсистема не должна иметь ограничений по количеству хранимых информационных объектов.
Создание Подсистемы должна быть осуществлено, исходя из следующих условий:
число одновременно работающих пользователей не менее 50;
количество ТС до 20000;
пиковые часы нагрузки Подсистемы — с 7:00 до 23:00.
В пиковые часы обслуживания потребителей услуг Подсистема должна обеспечить обработку не менее 300 транзакций/запросов в секунду.
Определение характеристик производительности Подсистемы в разных режимах функционирования, в зависимости от типа транзакций и используемого интерфейса передачи данных, должно быть результатом работ по настоящему ТЗ. Характеристики производительности Подсистемы должны быть уточнены на этапе технического проектирования.
Работоспособность Подсистемы не должна нарушаться при превышении указанной нагрузки, при этом допускается пропорциональное увеличение времени реакции или отказ в обслуживании отдельных запросов. После снижения нагрузки до установленного предела время реакции Подсистемы должно полностью восстановиться.
Подсистема не должна иметь ограничений по количеству хранимых информационных объектов.
В Подсистеме должна быть предусмотрена возможность масштабирования по производительности и объему обрабатываемой информации без модификации ее программного обеспечения путем модернизации используемого комплекса технических средств. Возможности масштабирования будут обеспечиваться средствами используемого базового программного обеспечения.
4.1.3.1.Количество пользователей
К показателям количества пользователей относятся:
расчетное количество пользователей;
расчетное количество одновременно работающих пользователей;
максимальное количество пользователей;
максимальное количество одновременно работающих пользователей.
Пояснения по показателям, связанным с количеством пользователей, приведены в таблице ниже (см. Таблица ).
Таблица - Определения показателей, связанных с количеством пользователей в Подсистеме
№
|
Показатель
|
Определение
|
|
Расчетное количество пользователей
|
Количество пользователей, работу которых должно обеспечить приложение к моменту сдачи ГК с учетом достижения всех показателей назначения
|
|
Расчетное количество одновременно работающих пользователей
|
Количество одновременно работающих пользователей, работу которых должно обеспечить приложение к моменту сдачи ГК с учетом достижения всех показателей назначения
|
|
Максимальное количество пользователей
|
Максимальное количество пользователей, работу которых должна обеспечить архитектура приложения
|
|
Максимальное количество одновременно работающих пользователей
|
Максимальное количество одновременно работающих пользователей, работу которых должна обеспечить архитектура приложения
|
Значения показателей количества пользователей, достижение которых необходимо обеспечить, представлено в таблице ниже (см. Таблица ).
Таблица - Значения показателей количества пользователей
№
|
Показатель
|
Значение
|
|
Расчетное количество пользователей
|
200
|
|
Расчетное количество одновременно работающих пользователей
|
100
|
|
Максимальное количество пользователей
|
400
|
|
Максимальное количество одновременно работающих пользователей
|
200
|
4.1.3.2.Число обрабатываемых объектов
К показателям числа обрабатываемых объектов относятся:
расчетное количество основных объектов предметной области обрабатываемых за час (по каждому типу обрабатываемого объекта);
расчетное количество основных объектов предметной области обрабатываемых за год (по каждому типу обрабатываемого объекта);
максимальное количество основных объектов предметной области обрабатываемых за час (по каждому типу обрабатываемого объекта);
максимальное количество основных объектов предметной области обрабатываемых за год (по каждому типу обрабатываемого объекта).
Перечень объектов, в отношении которых применяется данный показатель, приведен в таблице ниже (см. Таблица ).
Таблица - Перечень типов объектов, в отношении которых применяется показатель
№
|
Объект
|
Краткое описание
|
|
Источник измерения
|
К источникам измерений относятся ТС с установленными БНСО и датчиками, подключенными к БНСО
|
|
Параметр измерения
|
Параметр измерения – это структура данных содержащая навигационные и телеметрические показатели, полученные от БНСО, установленных на ТС
|
|
Результат измерения
|
Результат измерений – это набор структур данных, содержащих навигационные и телеметрические показатели ТС, передаваемые с определенной периодичностью
|
Пояснения по показателям, связанным с количеством объектов в Подсистеме, приведены в таблице ниже (см. Таблица ).
Таблица - Определения показателей, связанных с числом обрабатываемых Объектов
№
|
Показатель
|
Определение
|
|
Расчетное количество основных объектов предметной области обрабатываемых за час (по каждому типу обрабатываемого объекта)
|
Количество основных объектов предметной области, которое должно обрабатывать приложение за час времени к моменту сдачи ГК с учетом достижения всех показателей назначения
|
|
Максимальное количество основных объектов предметной области обрабатываемых за час (по каждому типу обрабатываемого объекта)
|
Максимальное количество основных объектов предметной области, обработку которых должна обеспечить архитектура приложения в течение часа
|
|
Расчетное количество основных объектов предметной области обрабатываемых за год (по каждому типу обрабатываемого объекта)
|
Количество основных объектов предметной области, которое должно обрабатывать приложение за год к моменту сдачи ГК с учетом достижения всех показателей назначения
|
|
Максимальное количество основных объектов предметной области обрабатываемых за год (по каждому типу обрабатываемого объекта)
|
Максимальное количество основных объектов предметной области, обработку которых должна обеспечить архитектура приложения в течение года
|
Значения показателей количества объектов Подсистемы, достижение которых необходимо обеспечить, представлено в таблице ниже (см. Таблица ).
Таблица - Значения показателей числа обрабатываемых Объектов
№
|
Объект
|
Количество объектов предметной области, обрабатываемых подсистемой
|
Расчетное
|
Максимальное
|
За час
|
За год
|
За час
|
За год
|
|
Результат измерения
|
2 млн.
|
17,52 млрд.
|
20 млн.
|
17,52 млрд.
|
4.1.3.3.Пропускная способность
К показателям пропускной способности относятся:
расчетное количество сообщений за час (по каждому информационному потоку);
максимальное количество сообщений за час (по каждому информационному потоку);
Пояснения по показателям, связанным с пропускной способностью Подсистемы, приведены в таблице ниже (см. Таблица ).
Таблица - Определения показателей, связанных с пропускной способностью
№
|
Показатель
|
Определение
|
|
Расчетное количество сообщений за час (по каждому информационному потоку)
|
Количество сообщений, которыми за час должно обмениваться приложение к моменту сдачи ГК с учетом достижения всех показателей назначения
|
|
Максимальное количество сообщений за час (по каждому информационному потоку)
|
Максимальное количество сообщений за час, которыми позволит обмениваться архитектура приложения
|
Значения показателей пропускной способности Подсистемы, достижение которых необходимо обеспечить, представлено в таблице ниже (см. Таблица ).
Таблица - Значения показателей пропускной способности Подсистемы
№
|
Наименование информационного потока
|
Тип передаваемого объекта
|
Количество сообщений за час
|
Расч.
|
Макс.
|
1
|
Получение аналитического отчета
|
Аналитический отчет
|
1000
|
2000
|
1
|
Получение сообщений системы
|
Сообщение системы
|
10000
|
20000
|
4.1.3.4.Время получения отчетности 4.1.3.4.1.Время получения отчетности с заранее определенной структурой
К показателям времени получения отчетности с заранее определенной структурой относятся:
расчетное время получения отчета с заранее определенной структурой (по каждому отчету);
максимальное время получения отчета с заранее определенной структурой (по каждому отчету).
Пояснения по показателям, связанным с получением отчетности с заранее определенной структурой, приведены в таблице ниже (см. Таблица ).
Таблица - Определения показателей, связанных с получением отчетности с заранее определенной структурой
№
|
Показатель
|
Определение
|
|
Расчетное время получения отчета с заранее определенной структурой (сек)
|
Время получения отчета с заранее определенной структурой к моменту сдачи ГК с учетом удовлетворения всех показателей назначения
|
|
Максимальное время получения отчета с заранее определенной структурой (сек)
|
Максимально допустимое время получения отчета с заранее определенной структурой
|
Значения показателей получения отчетности с заранее определенной структурой, достижение которых необходимо обеспечить, представлено в таблице ниже (см. Таблица ).
Таблица - Значения показателей получения отчетности с заранее определенной структурой
№
|
Наименование отчета
|
Расчетное время получения отчета с заранее определенной структурой (сек)
|
Максимальное время получения отчета с заранее определенной структурой (сек)
|
|
Аналитические отчеты по данным за сутки
|
5
|
15
|
|
Аналитические отчеты по данным за месяц
|
30
|
60
|
|
Аналитические отчеты по данным за год
|
300
|
600
|
Полный перечень отчетов должен быть уточнён Исполнителем на этапе технического проектирования.
4.1.4.Требования к надежности 4.1.4.1.Показатели доступности/надежности
К показателям доступности/надежности относятся:
доступность;
надежность;
время сохранности данных;
время восстановления после сбоя.
Пояснения по показателям, связанным с доступностью/надежностью, приведены в таблице ниже (см. Таблица ).
Таблица - Определения показателей, связанных с доступностью/надежностью
№
|
Показатель
|
Определение
|
|
Надежность, измеряется в часах
|
Надежность - мера того, как долго ИС может сохранять непрерывную работоспособность в рамках выполнения согласованных функций.
|
|
Доступность, измеряется в процентах
|
Доступность - способность ИС выполнять согласованною функцию в течении оговоренного времени ((время работы ИС - время простоя)/время работы ИС * 100).
|
|
Время сохранности данных (Recovery Point Objective - RPO), измеряется в часах
|
Время сохранности данных - допустимый период времени, за который могут быть утрачены данные
|
|
Время восстановления после сбоя (Recovery Time Objective - RTO), измеряется в часах
|
Время восстановления после сбоя - допустимое время восстановления работоспособности
|
Значения показателей доступности/надежности, достижение которых необходимо обеспечить, представлено в таблице ниже (см. Таблица ).
Таблица - Значения показателей доступности/надежности
№
|
Показатель
|
Значение
|
|
Надежность, измеряется в часах
|
5000 часов
|
|
Доступность, измеряется в процентах
|
99,5%
|
|
Время сохранности данных (Recovery Point Objective - RPO), измеряется в часах
|
12 часов
|
|
Время восстановления после сбоя (Recovery Time Objective - RTO), измеряется в часах
|
4 часа
| 4.1.4.2.Требования к программным мероприятиям по обеспечению надежности
Надежность Подсистемы должна достигаться комплексом организационных и технических мер, обеспечивающих требуемые уровни безотказности, ремонтопригодности, долговечности и сохранения ресурсов Подсистемы.
Технические меры по обеспечению надежности должны предусматривать:
резервирование критически важных компонентов и данных Подсистемы и отсутствие единой точки отказа;
использование технических средств с избыточными компонентами и возможностью их «горячей» замены;
использование программного резервирования (программной избыточности);
конфигурирование используемых средств и применение специализированного ПО, обеспечивающего высокую надёжность.
Организационные меры по обеспечению надежности должны быть направлены на минимизацию ошибок пользователей (а также обслуживающего персонала при эксплуатации и проведении работ по обслуживанию), минимизацию времени ремонта или замены вышедших из строя компонентов за счёт:
обеспечения требуемого уровня квалификации пользователей;
обеспечения требуемого уровня квалификации обслуживающего персонала;
регламентации и нормативного обеспечения выполнения работ обслуживающего персонала и пользователей;
своевременного оповещения пользователей о случаях нештатной работы компонентов Подсистемы;
своевременной диагностики неисправностей;
наличия запасных изделий;
наличия договоров на сервисное обслуживание и поддержку компонентов комплекса технических средств (КТС).
4.1.5.Требования к безопасности
Конструкция комплекса технических средств информационной системы (далее - ИС) должна обеспечивать безопасность обслуживающего персонала при эксплуатации, техническом обслуживании и ремонте.
При необходимости на видных местах технических средств должны быть нанесены предупреждающие знаки для обеспечения безопасности труда.
При монтаже и эксплуатации технических средств ИС должны быть соблюдены нормы электрической и противопожарной безопасности. Выбор конкретных стандартов и норм должен производиться на этапе рабочего проектирования.
Помещения должны быть оборудованы средствами пожаротушения для электрооборудования, и соответствовать правилам противопожарной безопасности.
Электробезопасность должна соответствовать требованиям ГОСТ 12.1.030-81 «Система стандартов безопасности труда. Электробезопасность. Защитное заземление, зануление».
Аппаратное обеспечение Подсистемы должно соответствовать требованиям пожарной безопасности в производственных помещениях по ГОСТ 12.1.004-91. «ССБТ. Пожарная безопасность. Общие требования».
Должно быть обеспечено соблюдение общих требований безопасности в соответствии с ГОСТ 12.2.003-91. «ССБТ. Оборудование производственное. Общие требования безопасности» при обслуживании Подсистемы в процессе эксплуатации.
Аппаратная часть Подсистемы должна быть заземлена в соответствии с требованиями ГОСТ Р 50571.22-2000. «Электроустановки зданий. Часть 7. Требования к специальным электроустановкам. Раздел 707. Заземление оборудования обработки информации».
Технические средства должны отвечать действующей системе государственных стандартов безопасности труда и иметь сертификаты по электробезопасности и электромагнитной безопасности.
Значения эквивалентного уровня акустического шума, создаваемого аппаратурой Системы, должно соответствовать ГОСТ 21552-84, но не превышать следующих величин:
50 дБ - при работе технологического оборудования и средств вычислительной техники без печатающего устройства;
60 дБ - при работе технологического оборудования и средств вычислительной техники с печатающим устройством.
В помещениях должны поддерживаться параметры микроклимата в соответствии с требованиями, предъявляемыми поставщиками размещаемого там оборудования.
На этапе «Ввода в эксплуатацию» Подсистемы Исполнителем должны выполняться меры электробезопасности в соответствии с «Правилами устройства электроустановок» и «Правилами техники безопасности при эксплуатации электроустановок потребителей».
Предоставленное Заказчиком аппаратное обеспечение Подсистемы должно соответствовать требованиям пожарной безопасности в производственных помещениях по ГОСТ 12.1.004-91.
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.7.1.Условия и регламент (режим) промышленной эксплуатации
Должно быть предусмотрено ежедневное/еженедельное техническое обслуживание Подсистемы.
Требования к срокам и периодичности проведения работ по техническому обслуживанию для каждой из подсистем не установлены.
4.1.7.2.Требования к составу, размещению и условиям хранения комплекта запасных изделий и приборов
Требования к составу, размещению и условиям хранения комплекса запасных изделий и приборов не предъявляются.
4.1.7.3.Требования к регламенту обслуживания
При промышленной эксплуатации Подсистемы входящее в ее состав системное программное и аппаратное обеспечение должно соответствовать рекомендациям производителя.
Должны соблюдаться правила эксплуатации компонентов Подсистемы, а также производиться своевременная установка обновлений программного обеспечения, рекомендованных производителями.
Исполнителем должны быть предъявлены требования к ежедневному и еженедельному обслуживанию, а также обслуживанию по возникновению особых (исключительных) ситуаций. Сюда включаются работы по обслуживанию технических средств Подсистемы, данных в постоянных и временных хранилищах (базах данных), потоков сообщений в электронных коммуникациях, паролей и прав доступа.
В частности, в обслуживание входят работы:
по сохранению (копированию) журналов изменений баз данных и резервных копий баз данных;
по восстановлению баз данных при порче или разрушении данных;
по профилактическому контролю состояния дисковых запоминающих устройств и данных на них.
Выполнение указанных требований должно обеспечивать непрерывную работу комплекса. При этом резервное копирование информации может осуществляться в двух режимах:
создание полной копии базы данных;
сохранение изменений, внесенных со времени создания последней архивной копии (архивные копии log-файлов).
Периодичность и очередность этих операций определяются политикой резервного копирования информации площадкой размещения.
Создание полной копии базы данных осуществляется полным копированием всех файлов указанной базы на внешние носители.
При сохранении изменений, внесенных со времени создания последней архивной копии, на внешние носители переносятся только те изменения базы данных, которые были сделаны со времени или после последней операции архивирования (полного или частичного).
При восстановлении информации с архивных копий сначала с архивных носителей восстанавливается состояние базы данных на момент последней операции полного резервного копирования, затем в базу поочередно вносятся изменения со всех частичных архивов, созданных после полного резервирования.
Предпочтительный интервал для технического обслуживания Подсистемы в нерабочие дни, например, с 23:00 до 07:00.
При промышленной эксплуатации Подсистемы должен соблюдаться регламент обновления, входящего в ее состав системного программного обеспечения.
Должно поддерживаться функционирование эталонной и промышленной платформ Подсистемы.
Версии системного программного обеспечения, версии сборок прикладного программного обеспечения, созданного Исполнителем, и настройки, не связанные с IP-адресацией и URL веб сервисов, должны быть идентичны на обеих платформах.
На эталонной платформе Подсистемы не должна вестись разработка. Эталонная платформа Подсистемы должна быть предназначена только для тестирования функциональных возможностей и тестирования обновлений версий ППО и СПО.
Любые изменения или обновления версий ППО и СПО на эталонной платформе Подсистемы должны применяться только в случае успешного проведения аналогичных работ на тестовой платформе Исполнителя.
Обновление версий ППО на эталонной платформе Подсистемы должно осуществляться специалистами Исполнителя. Заказчик обеспечивает доступ к компонентам (серверам) своей эталонной платформы Подсистемы по протоколу RDP (Remote Desktop Protocol) для технических специалистов Исполнителя с соответствующими правами доступа, необходимыми для осуществления функций управления (администрирования) и тестирования.
В случае использования СПО или Open Source компонентов и шаблонных компонентов должны быть проведены организационные работы по заключению договора на техническую поддержку и обслуживание. Исполнитель также должен разработать методику использования Open Source компонентов при модернизации системы.
4.1.8. Требования к защите информации от несанкционированного доступа 4.1.8.1.Общие, функциональные требования и требования к эффективности обеспечения безопасности информации
В ходе выполнения работ по модернизации Подсистемы необходимо осуществить выполнение следующих работ:
Оценить влияние создаваемых подсистем на уровень информационной безопасности Подсистемы в целом;
Оценить соответствие существующей системы информационной безопасности требованиям документов, регламентирующих вопросы защиты информации.
По результатам проведения указанных работ должны быть скорректированы или разработаны:
требования по обеспечению информационной безопасности;
проект акта классификации Подсистемы;
модель угроз и нарушителя.
Модель угроз информационной безопасности должна определять:
защищаемые объекты;
основные угрозы безопасности информации, включая угрозы техногенного характера, стихийные бедствия и угрозы, реализуемые нарушителями;
критерии уязвимости Подсистемы к деструктивным воздействиям.
классификацию типов возможных нарушителей информационной безопасности;
предположения об имеющейся у нарушителя информации;
основные каналы, цели и объекты атак;
предположения об имеющихся у нарушителя средствах;
перечень атак.
4.1.8.2.Технические требования по защите информации
При разработке программного кода Исполнитель должен применять методы безопасного программирования, включающие:
ручную и автоматизированную проверку кода на предмет НДВ;
использование при разработке доверенной аппаратной платформы с функциями защиты от НДВ на системном и прикладном уровне;
контроль версионности исходного кода;
тестирование информационной системы на проникновения (пинтесты).
Детализированные требования к обеспечению информационной безопасности, а также требования по разработке организационно-распорядительных документов по обеспечению информационной безопасности, должны быть уточнены на этапах технического проектирования.
4.1.9.Требования по сохранности информации при авариях
Сохранность информации в Подсистеме должна обеспечиваться:
при разрушении данных при механических и электронных сбоях и отказах в работе компьютеров: на основе программных процедур восстановления информации с использованием хранимых копий баз данных, файлов журналов изменений в базах данных, копий программного обеспечения.
Для обеспечения сохранности информации в Подсистеме должны быть включены следующие функции:
резервное копирование баз данных Подсистемы;
восстановление данных в непротиворечивое состояние при программно-аппаратных сбоях (отключение электрического питания, сбоях операционной Подсистемы и других) вычислительно-операционной среды функционирования;
восстановление данных в непротиворечивое состояние при сбоях в работе сетевого программного и аппаратного обеспечения.
4.1.9.1.Перечень событий, при которых должна быть обеспечена сохранность информации в подсистеме
В Подсистеме должно предусматриваться автоматическое восстановление обрабатываемой информации в следующих аварийных ситуациях:
программный сбой при операциях записи/чтения;
разрыв связи с клиентской программой (терминальным устройством) в ходе редактирования/обновления информации.
В Подсистеме должна предусматриваться возможность ручного восстановления обрабатываемой информации из резервной копии в следующих аварийных ситуациях:
физический выход из строя дисковых накопителей;
ошибочные действия обслуживающего персонала.
В Подсистеме должно предусматриваться автоматическое восстановление работоспособности серверной части Подсистемы в следующих ситуациях:
штатное и аварийное отключение электропитания серверной части;
штатная перезагрузка Подсистемы и загрузка после отключения;
программный сбой общесистемного программного обеспечения, приведший к перезагрузке системы.
В Подсистеме должно предусматриваться полуавтоматическое восстановление работоспособности серверной части Подсистемы в следующих аварийных ситуациях:
физический выход из строя любого аппаратного компонента, кроме дисковых накопителей — после замены компонента и восстановления конфигурации общесистемного программного обеспечения;
аварийная перезагрузка системы, приведшая к нефатальному нарушению целостности файловой системы — после восстановления файловой системы.
4.1.9.2.Требования к регламентам и объемам резервного копирования и архивирования данных
Резервное копирование информации может осуществляться в двух режимах:
создание полной копии базы данных;
сохранение изменений, внесенных со времени создания последней архивной копии (архивные копии log-файлов).
Периодичность и очередность этих операций определяются политикой резервного копирования информации площадкой размещения.
Создание полной копии базы данных осуществляется полным копированием всех файлов указанной базы на внешние носители.
При сохранении изменений, внесенных со времени создания последней архивной копии, на внешние носители переносятся только те изменения базы данных, которые были сделаны со времени или после последней операции архивирования (полного или частичного).
4.1.10.Требования к патентной чистоте 4.1.10.1.Перечень стран, в отношении которых должна быть обеспечена патентная чистота подсистемы и ее частей
Патентная чистота программного комплекса и его частей должна быть обеспечена в отношении патентов, действующих на территории РФ.
Реализация технических, программных, организационных и иных решений, предусмотренных проектом Подсистемы, не должна приводить к нарушению авторских и смежных прав третьих лиц.
4.1.10.2.Требования к использованию лицензионного программного обеспечения
При использовании в Подсистеме программ (программных комплексов или компонентов), разработанных третьими лицами, условия, на которых передается право на использование (исполнение) этих программ, не должны накладывать ограничений, препятствующих использованию Подсистемы по ее прямому назначению. Точный состав и количество лицензий на ПО, необходимое для запуска модернизированных компонентов Подсистемы в промышленную эксплуатацию, должно быть указано в Ведомости покупных изделий технического проекта.
4.1.11. Требования по стандартизации и унификации
Разработка программного обеспечения ПСД АСУ ОДС должна выполняться с использованием стандартных и унифицированных методов разработки программных средств, входящих в состав используемых систем автоматизированного проектирования и разработки. Система проектирования должна обеспечивать унификацию функциональных задач, операций и интерфейсов в части их реализации.
Системное программное обеспечение должно быть унифицировано по версиям и составу в рамках автоматизированных рабочих мест. Необходимо максимально использовать типовые поставляемые решения, лицензионное и сертифицированное программное обеспечение (операционные системы, СУБД, системы формирования и ведения отчетности, средства защиты информации и разграничения доступа и т.д.).
В составе Подсистемы применены унифицированные в рамках сферы деятельности ДЖКХиБ и смежных организаций классификаторы и справочники. Предусмотрена возможность централизованного ведения и актуализации НСИ.
Экранные формы должны проектироваться с учетом требований унификации:
все экранные формы пользовательского интерфейса должны быть выполнены в едином графическом дизайне, с одинаковым расположением основных элементов управления и навигации;
для обозначения одних и тех же операций должны использоваться одинаковые графические значки, кнопки и другие управляющие (навигационные) элементы;
должны быть унифицированы термины, используемые для описания идентичных понятий, операций и действий пользователя;
реакция системы на действия пользователя (наведение указателя «мыши», переключение фокуса, нажатие кнопки) должна быть типовой для каждого действия над одними и теми же графическими элементами, независимо от их расположения на экране.
4.1.12. Дополнительные требования 4.1.12.1.Требования к оснащению подсистемы устройствами для обучения персонала и документацией на них
Требования к оснащению Подсистемы устройствами для обучения персонала (тренажеры, другие устройства аналогичного назначения) не установлены.
4.1.12.2.Требования к Подсистеме, связанные с особыми условиями эксплуатации
Требования к подсистеме, связанные с особыми условиями эксплуатации не установлены.
4.1.12.3.Требования по сертификации Подсистемы, ее компонентов
Требования к подсистеме, связанные с сертификацией подсистемы или ее компонентов не установлены.
4.1.13.Специальные требования
При создании Подсистемы должен применяться итерационный (модульный) подход в зависимости от длительности и сложности разработки.
Технические средства, необходимые для размещения разрабатываемого решения, предоставляются Заказчиком.
Исполнитель должен сформулировать предложение по размещению подсистемы, исходя из заданных параметров производительности, доступности и информационной безопасности. Предложение по размещению в части требуемых мощностей должно быть описано в документе «Описание архитектуры», обосновано результатами нагрузочного тестирования и согласовано с Заказчиком.
4.1.14.Требования к электронным учебным курсам 4.1.14.1.Требования по соответствию электронных курсов международным стандартам
Электронные учебные курсы должны полностью соответствовать требованиям стандарта SCORM 2004. (Разработчик стандарта Advanced Distributed Learning (ADL) http://www.adlnet.org/)
Согласно требованиям SCORM 2004, электронные учебные курсы должны содержать три основных компонента:
язык взаимодействия программ (run-time communications) — стандартный язык, на котором обучающая программа «общается» с системой дистанционного обучения (СДО);
метаданные о курсе. Каждый фрагмент курса должен соотноситься с определенным файлом метаданных, в котором содержатся указания на то, что этот фрагмент собой представляет и где находится;
файл-манифест / пакет содержания (Content package). Этот файл содержит полное описание курса обучения и составляющих его файлов. Документ (The manifest) о Едином пакете содержания (Content Packages) SCORM описывается через Extensible Markup Language (XML) (файл “imsmanifest.xml”).
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.
|
