4.2Общие требования к Системе
АИС УЗ должна обеспечивать формирование, обработку, хранение и предоставление данных на всех этапах формирования потребностей, планирования и осуществления закупок, мониторинга закупок, аудита в сфере закупок, контроля за соблюдением законодательства Российской Федерации и иных нормативных правовых актов в сфере закупок товаров, работ, услуг, а также автоматизацию деятельности подразделений ФГУП «Почта России» в сфере проведения закупок, контроля выполнения договоров.
Создаваемые компоненты АИС УЗ должны:
соответствовать требованиям 223-ФЗ и Положения о закупках;
интегрироваться с системами, указанными в разделе 2.1 «Назначение Системы». Технические параметры интегрируемых систем будут учтены в соответствующих регламентах на этапах «Подготовка подсистем в части взаимодействия с Министерством и ЭТП к опытно-промышленной эксплуатации и ее проведение на примере пилотной зоны», «Обследование объекта автоматизации и документирование проектных решений в части подсистем сбора и консолидации потребностей», «Обследование объекта автоматизации и документирование проектных решений в части подсистем управления запасами»
поддерживать разделение ландшафтов на ландшафты разработки, тестирования, продуктивный ландшафт с возможностью контролируемого переноса изменений между подсистемами.
Система должна быть спроектирована на основании следующих принципов:
-
Принцип концептуального единства
Организационное, техническое, программное, информационное и лингвистическое обеспечение должно быть реализовано на единых системных концепциях, определенных для Системы в целом.
-
Принцип развития (модифицируемости)
В Системе должна обеспечиваться возможность модификации с учетом изменений нормативной базы, а также требований, предъявляемых Заказчиком в процессе её эксплуатации, за счет использования широко распространенных и унифицированных методов и средств проектирования и разработки информационных автоматизированных систем.
-
Принцип модульности
Принцип модульности должен обеспечиваться на уровне ПО путем вычленения задач и комплексов задач, подлежащих автоматизации с декомпозицией их по функциональному назначению. При этом должны определяться минимально необходимые связи между автоматизируемыми комплексами задач для повышения надежности и работоспособности подсистем, а также их адаптируемости к изменяющимся внешним условиям.
-
Принцип открытости
Система должна быть создана таким образом, чтобы была обеспечена возможность интеграции в свою среду новых подсистем и расширения функций уже имеющихся подсистем за счет модульного принципа их построения, а также использования принятых в мире стандартов на правила передачи (протоколы, интерфейсы) и хранения информации.
-
Принцип многоуровневости
Система должна иметь многоуровневую архитектуру:
уровень получения данных — должен обеспечивать информационное взаимодействие с используемой системой управления базами данных (далее — СУБД);
уровень функциональной обработки данных — должен обеспечивать обработку данных в соответствии с функциональными требованиями;
уровень визуализации обработанных данных — должен обеспечивать отображение обработанных данных для пользователя.
-
Принцип санкционированного доступа к информации
Должно быть реализовано:
разделение прав доступа пользователей к документам, формируемым в ходе подготовки и размещения закупки, контроля за выполнением договоров;
возможность ограничения доступа пользователей к определенным формам, полям форм, а также записям и программной логике.
Принцип масштабируемости
Система должна обеспечивать возможности горизонтального и вертикального масштабирования для обеспечения отказоустойчивости и достаточной производительности при следующих изменениях:
при увеличении количества пользователей;
при росте объемов накопленных данных.
Принцип отказоустойчивости
- Система должна быть устойчива к единичным отказам оборудования или системного ПО на котором она функционирует
- Компоненты и данные системы должны размещаться на разных площадках (основной и резервный ЦОД) и позволять переключаться на резервный ЦОД в случае выхода из строя основного ЦОД
Принцип адаптируемости
Система должна поддерживать возможность адаптации к различным организационным и техническим изменениям Предприятия без использования программирования, включая изменение бизнес-процессов и отчетов .
Требования к структуре и функционированию Системы
Перечень подсистем
Система должна быть построена на модульной основе с общим для всех модулей хранилищем данных и системой авторизации:
подсистема формирования потребностей;
подсистема обоснования начальной (максимальной) цены;
подсистема планирования закупок;
подсистема подготовки документации о закупках;
подсистема размещения закупок;
подсистема исполнения Договоров и управления поставщиками;
подсистема учета и управления запасами;
подсистема информационного взаимодействия с ЕИС;
подсистема ведения справочников и классификаторов;
подсистема формирования аналитических отчетов;
подсистема уведомления пользователей;
подсистема интеграции с информационной системой взаимодействия с Министерством АИС «Независимый регистратор сделок»;
подсистема функционального администрирования;
подсистема информационной безопасности.
Детальное описание функций подсистем изложено в п.4.3.
Требования к способам и средствам связи для информационного обмена между компонентами Системы
АИС УЗ должна быть организована по типу архитектуры клиент-сервер (клиент – сервер web-приложений – СУБД).
В качестве основного средства связи между компонентами Системы должна быть использована локальная вычислительная сеть, построенная по технологии Ethernet (конкретная реализация технологии должна быть определена на стадии проектирования).
Входящие в состав АИС УЗ подсистемы в процессе функционирования должны вести обмен информацией на основе задокументированных форматов обмена данными, с обеспеченным соответствующим уровнем информационной безопасности.
В качестве базового протокола сетевого и межсетевого взаимодействия должен использоваться протокол TCP/IP.
Требования к характеристикам взаимосвязей Системы с другими системами
В Системе должен быть реализован способ установления взаимосвязей со смежными и внешними системами с целью трансляции их содержания в Системе и обратной трансляции в смежных и внешних системах. Система должна поддерживать раздачу справочника номенклатуры товаров, работ, услуг по принципам работы систем, управляющих номенклатурно-справочной информацией.
Доступ пользователей должен осуществляться с помощью «тонкого» клиента, где в качестве «тонкого» клиента должен использоваться web-браузер.
При реализации взаимодействия должны быть обеспечены следующие параметры безопасности: аутентификация и авторизация источника передаваемой информации. Процедура авторизации должна осуществляться путем ввода пользователем логина и пароля, выданного при его аккредитации. Аккредитация пользователей должна осуществляться за счет использования данных Active Directory. Должна быть предусмотрена процедура генерации логина и пароля администратором Системы. Администратор, аккредитуя пользователя, подтверждает введенные данные и устанавливает срок действия логина и пароля. Администраторы Системы могут обращаться к серверу, как через web-интерфейс, так и непосредственно к файловой системе сервера, используя авторизацию ОС.
Интеграция со смежными системами
К смежным системам относятся системы, указанные в п. 2.1.
В ходе обследования объекта автоматизации на примере пилотной зоны Исполнитель должен разработать описание автоматизируемых бизнес-процессов (в т. ч. схемы процессов, «as is» и «to be» модели, описание точек интеграции, информационных потоков), а также подготовить и согласовать с Заказчиком предложения по оптимизации.
Исполнителем должны быть выполнены работы по унификации справочников и словарей, необходимых для обеспечения корректного обмена данными. В ходе обследования Исполнителем должны быть представлены предложения по доработкам смежных информационных систем, необходимых для корректного информационного обмена с АИС УЗ согласованного объема данных, а также требующихся для автоматизации сквозного бизнес-процесса управления потребностями ФГУП «Почта России».
Требования к характеристикам взаимосвязей создаваемой Системы со смежными системами, требования к их совместимости, в том числе указания о способах обмена информацией (автоматически или пересылкой документов) должны быть уточнены в соответствующих «проектах регламентов информационного обмена со смежными системами».
Взаимодействие смежных систем должно осуществляться в соответствии с согласованными с Заказчиком форматами и проектами регламентов информационного обмена со смежными системами, разрабатываемыми на этапах «Подготовка подсистем в части взаимодействия с Министерством и ЭТП к опытно-промышленной эксплуатации и ее проведение на примере пилотной зоны», «Обследование объекта автоматизации и документирование проектных решений в части подсистем сбора и консолидации потребностей», «Обследование объекта автоматизации и документирование проектных решений в части подсистем управления запасами».
Интеграция с ЕИС
Взаимодействие с Общероссийским официальным сайтом -http://zakupki.gov.ru (до ввода ЕИС в эксплуатацию) для размещения информации о размещении заказа должна осуществляться в соответствии с «Альбомом форматов XML-документов передаваемых в электронной форме по телекоммуникационным каналам связи в рамках интеграции Общероссийского официального сайта со смежными системами».
АИС УЗ должна позволять размещать на ООС (ЕИС) всю информацию, размещение которой предусмотрено 223-ФЗ и требованиями Положения о закупках товаров, работ, услуг для нужд ФГУП «Почта России» (№ 187-п от 30.06.2014 г), в том числе:
Положение о закупке и изменения, вносимые в Положение о закупке;
структурированный годовой План закупки товаров, работ, услуг и изменения к нему;
извещение о проведении закупки и изменения к ней;
документация к процедуре закупки и разъяснения, изменения к ней;
протоколы, составляемые в ходе закупки;
сведения о количестве и об общей стоимости договоров, заключенных заказчиком по результатам закупки товаров, работ, услуг;
сведения о количестве и об общей стоимости договоров, заключенных заказчиком по результатам закупки у единственного поставщика (исполнителя, подрядчика);
сведения о количестве и об общей стоимости договоров, заключенных заказчиком по результатам закупки, сведения о которой составляют государственную тайну или в отношении которой приняты решения Правительства Российской Федерации в соответствии с частью 16 статьи 4 223-ФЗ;
сведения о количестве и об общей стоимости договоров, заключенных заказчиком по результатам закупки у субъектов малого и среднего предпринимательства;
договоры, информация об изменении договоров, сведения о заключенных договорах;
иные документы, оформляемые в ходе проведения процедуры закупки;
АИС УЗ должна формировать отчет о размещении на ООС (ЕИС) перечисленных документов.
Интеграция с ЭТП
АИС УЗ должна позволять размещать на нескольких ЭТП (не менее пяти) всю информацию, размещение которой предусмотрено 223-ФЗ (в том числе посредством взаимодействия с ЕИС) и требованиями Положения о закупках товаров, работ, услуг для нужд ФГУП «Почта России» (№ 187-п от 30.06.2014 г), в том числе:
Положение о закупке и изменения, вносимые в Положение о закупке;
извещение о проведении закупки, документацию о закупке, проект договора как неотъемлемую часть документации о закупке и изменения, вносимые в извещение о проведении закупки, в документацию о закупке, обоснование начальной (максимальной) цены договора;
разъяснения документации о закупке;
протоколы, составляемые в ходе проведения закупки;
сведения о количестве и об общей стоимости договоров, информация об изменении договоров, в том числе дополнительные соглашения; иные документы, оформляемые в ходе проведения закупки.
АИС УЗ должна формировать отчет о размещении на ЭТП перечисленных документов.
АИС УЗ должна обеспечивать в случае необходимости возможность подписания документов квалифицированной электронной подписью (в соответствии с требованиями ЭТП), а также проверку ее валидности за счет данных УЦ.
Перечисленный функционал должен быть доступен как ответственным работникам аппарата управления, так и соответствующим работникам в филиалах.
Требования к режимам функционирования Системы
Система должна функционировать в двух основных режимах:
в пользовательском режиме;
в режиме настройки.
Характеристики пользовательского режима функционирования Системы:
клиентское ПО и технические средства пользователей и администратора системы обеспечивают возможность функционирования круглосуточно, семь дней в неделю, с перерывами на техническое обслуживание в нерабочее время (в период с 22:00 до 2:00 по московскому времени);
серверное ПО и технические средства серверов обеспечивают возможность круглосуточного функционирования, с перерывами на обслуживание в нерабочее время;
исправно работает оборудование, составляющее комплекс технических средств;
исправно функционирует системное, базовое и прикладное ПО системы.
Требования по диагностированию
Диагностирование Системы должно обеспечивать выявление неработоспособности технических средств, базового и прикладного ПО.
Все подсистемы, входящие в состав АИС УЗ, должны иметь средства и процедуры диагностирования.
Система не должна требовать использования нештатных режимов работы серверов баз данных, серверов приложений, межсетевых экранов и каналов связи для выполнения диагностики.
Система должна обеспечивать своевременное оповещение обслуживающего персонала Системы о наступивших нарушениях работоспособности.
Должно существовать однозначное соответствие между нарушениями работоспособности и оповещениями Системы, т.е. Система должна выдавать одинаковые оповещения для одинаковых нарушений работоспособности.
Оповещения Системы обслуживающему персоналу должны содержать:
описание нарушения работоспособности Системы;
подсистему, в которой обнаружено нарушение работоспособности.
Требования к масштабированию и модернизации Системы
Направления, в которых Система должна предусматривать модернизацию:
изменение оборудования серверов в части увеличения мощности процессора, объема жесткого диска и увеличения оперативной памяти;
изменение количества серверов. Система должна допускать расположение сервера базы данных на выделенном сервере.
Система должна предусматривать возможность расширения числа функциональных подсистем;
Система должна предусматривать возможность расширения числа зарегистрированных пользователей;
возможность поддержки одновременной работы до нескольких десятков тысяч пользователей при соблюдении требований к времени отклика, установленного в п 4.2.3.
Требования к численности, квалификации персонала и режиму его работы
Персонал АИС УЗ должен включать следующие категории:
администратор Системы;
пользователи.
Администратор Системы контролирует функционирование и обеспечение безопасности работы Системы в целом, осуществляет функции по аккредитации пользователей Системы, взаимодействует со специалистами внешней организации, обеспечивающей техническое обслуживание Системы.
Администраторы Заказчика и пользователи АИС УЗ должны пройти обучение работе в Системе у Исполнителя: очное для администраторов и пользователей АУП, дистанционное – путем изучения обучающих видео курсов и инструкций по работе с Системой. Обучение пользователей должно завершаться выполнением проверочных заданий.
Показатели назначения
Система должна быть разработана с учетом требований нормативно-распорядительных документов, перечень которых указан в разделе 3.2 «Сведения об объекте автоматизации».
Система должна выполнять свои функции при следующих условиях:
количество подразделений – 46 600;
количество зарегистрированных пользователей – 62 000
Время отклика АИС УЗ в части запуска Системы, авторизации пользователя, открытия пользовательских объектов Системы (карточка закупки, справочник потребностей и т.д.) и выполнения базовых операций work-flow (отправка на согласование, консолидация потребностей, внесение изменений в карточку закупки и т.д.) не должно превышать 5 сек. Параметр будет детализирован в рамках подготовки к проведению нагрузочного тестирования Системы.
Система должна иметь приспособляемость к изменению следующих параметров:
изменения маршрута следования заявок;
изменения форм документов по закупкам;
изменения состава комиссий после опубликования информации о закупке;
изменения форм отчетных документов.
В Системе должна иметься поддержка форматов офисных приложений (Word, Excel, PowerPoint, Visio, Project), форматов цифровых файлов (изображения, видео и т.д.), форматов PDF, TIFF, веб-форматов. Детальные требования к объему используемых в АИС УЗ функций перечисленных форматов должны быть определены при формировании частных технических заданий на подсистемы.
Система должна предусматривать возможность хранения данных в течение 10 лет после вывода её из промышленной эксплуатации.
Требования к надежности
АИС УЗ должна удовлетворять следующим требованиям по надежности Системы:
максимальное время на восстановление работоспособности АИС УЗ – не более 8 часов;
резервирование критически важных компонентов и данных Системы и отсутствие единой точки отказа;
компоненты системы и данные должны размещаться в двух центрах обработки данных (ЦОД) Заказчика. Выход из строя одного из ЦОД не должно приводить к неработоспособности Системы
конфигурирование используемых средств и применение специализированного ПО, обеспечивающего их высокую доступность.
работоспособность Системы и целостность данных не должна зависеть от работоспособности клиентских рабочих мест;
Показатели надежности программного обеспечения должны достигаться комплексом организационно-технических мер обеспечивающих доступность ресурсов, их управляемость и обслуживаемость. Надежность ПО должна определяться надежностью функциональных подсистем.
Требования к эргономике и технической эстетике
Взаимодействие пользователей с прикладным ПО, входящим в состав Системы, должно осуществляться посредством визуального графического интерфейса (GUI). Интерфейс АИС УЗ должен быть понятным и удобным, не должен быть перегружен графическими элементами и должен обеспечивать быстрое отображение экранных форм. Навигационные элементы должны быть выполнены в удобной для пользователя форме. Средства редактирования информации должны удовлетворять принятым соглашениям в части использования функциональных клавиш, режимов работы, поиска, использования оконной системы. Ввод-вывод данных Системы, прием управляющих команд и отображение результатов их исполнения должны выполняться в интерактивном режиме. Интерфейс должен соответствовать современным эргономическим требованиям и обеспечивать удобный доступ к основным функциям и операциям Системы.
Все надписи экранных форм, а также сообщения, выдаваемые пользователю (кроме системных сообщений) должны быть на русском языке. В случае неверных действий пользователей Система должна показывать подсказки по дальнейшим действиям, а также обеспечить возможность открытия руководства пользователя на соответствующем разделе.
Система должна обеспечивать контроль заполнения экранных форм.
Система должна обеспечивать корректную обработку аварийных ситуаций, вызванных неверными действиями пользователей, неверным форматом или недопустимыми значениями входных данных. В указанных случаях Система должна выдавать пользователю соответствующие сообщения, после чего возвращаться в рабочее состояние, предшествовавшее неверной (недопустимой) команде или некорректному вводу данных.
Дизайн интерфейсов АИС УЗ должен предусматривать использование следующих элементов оформления:
фирменные цвета и графика ФГУП «Почта России»;
четкие, контрастные шрифты;
общепринятые элементы навигации и иконки;
Экранные формы, команды меню, внешний вид подсистем, шрифты, другие элементы оформления должны быть выбраны на основе существующих тенденций в сфере веб-дизайна.
Экранные формы должны проектироваться с учетом требований унификации:
все экранные формы пользовательского интерфейса должны быть выполнены в едином графическом дизайне, с одинаковым расположением основных элементов управления и навигации;
для обозначения сходных операций должны использоваться сходные графические значки, кнопки и другие управляющие (навигационные) элементы. Термины, используемые для обозначения типовых операций (добавление информационной сущности, редактирование поля данных), а также последовательности действий пользователя при их выполнении, должны быть унифицированы;
внешнее поведение сходных элементов интерфейса (реакция на наведение указателя «мыши», переключение фокуса, нажатие кнопки) должны реализовываться одинаково для однотипных элементов.
Должны быть проведены работы по обследованию (с использованием фокус-групп), разработке, согласованию и утверждению «юзабилити» Системы в соответствии с рекомендациями стандартов:
ISO 9241-11
ISO 13407
ISO 18529
ISO 16982
В ходе работ должен быть достигнут и согласован оптимальный уровень эффективности использования Системы целевой группой пользователей при решении ими конкретных задач, а также степень их удовлетворенности работой в этой системе.
Требования к эксплуатации, техническому обслуживанию, ремонту и хранению компонентов Системы
АИС УЗ должна обеспечивать доступ Пользователей к разделам Системы в соответствии с режимом функционирования объекта автоматизации.
Регламент обслуживания Системы должен определять порядок взаимодействия между подразделениями пользователей, администраторов Системы и службой технической поддержки Исполнителя.
Периодическое техническое обслуживание используемых технических средств должно проводиться в соответствии с требованиями технической документации изготовителей, но не реже одного раза в год. Техническое обслуживание должно занимать не более 5 часов в месяц и проводиться в нерабочее время в период с 22:00 до 2:00 по московскому времени.
Восстановление работоспособности технических средств должно проводиться в соответствии с инструкциями разработчика документами по восстановлению работоспособности технических средств и завершаться проведением их тестирования. При вводе Системы в опытную эксплуатацию должен быть разработан план выполнения резервного копирования программного обеспечения и обрабатываемой информации и включен в документ «Регламент обслуживания Системы».
Должно обеспечиваться создание резервной копии Системы не реже 1 раза в сутки. Процедура резервного копирования не должна влиять на функционирование Системы.
Хранение резервных копий Системы должно осуществляться на внешних носителях информации (другой сервер, лента, диск и т.п.).
Система должна быть рассчитана на эксплуатацию в составе программно–технического комплекса Заказчика.
Требования к защите информации от несанкционированного доступа
При создании и эксплуатации Системы необходимо соблюдать требования следующих нормативных документов в части обеспечения защиты информации:
- Федеральный закон от 27.07.2006 № 149-ФЗ «Об информации, информационных технологиях и о защите информации»;
- Федеральный закон от 27.07.2006 № 152-ФЗ «О персональных данных»;
- ГОСТ Р 51583-2014.
Перечень защищаемых данных, включая, но не ограничиваясь, персональные данные, обрабатываемых в Системе уточняется на этапе проектирования Системы.
С учетом целей, задач, архитектуры Системы, перечня защищаемых данных, возможных негативных последствий для Заказчика (возможного финансового и репутационного ущерба) должна быть разработана модель актуальных угроз информационной безопасности системы. Для разработанной модели актуальных угроз также должна разрабатываться модель защиты.
Модели актуальных угроз и модели защиты для персональных данных и остальной защищаемой информации могут разрабатываться отдельно.
В состав (структуру) подсистемы защиты информации могут входить следующие компоненты:
- идентификации и аутентификации субъектов доступа и объектов доступа;
- управления доступом субъектов доступа к объектам доступа;
- ограничения программной среды;
- защиты машинных носителей;
- регистрации событий безопасности;
- антивирусной защиты;
- обнаружения вторжений;
- контроля (анализа) защищённости;
- обеспечения целостности информационной системы и защищаемых данных;
- обеспечения доступности данных;
- защиты среды виртуализации;
- защиты технических средств;
- защиты информационной системы, ее средств, систем связи и передачи данных;
- выявления инцидентов и реагирования на них;
- управления конфигурацией информационной системы и системы защиты.
Состав подсистемы защиты информации уточняется по результатам разработки модели актуальных угроз и модели защиты.
Состав необходимых защитных мер в рамках каждой компоненты должен быть определен на основании руководящих документов ФСТЭК и ФСБ России.
Исполнитель может в качестве одного из способов защиты информации применять методы обезличивания в соответствии с Приказом Роскомнадзора от 05.09.2013 г. № 996 и методическими рекомендациями по их использованию.
Выбор средств защиты должен производиться с учётом эксплуатируемых либо планируемых к внедрению в рамках реализации других проектов по информационной безопасности во ФГУП «Почта России» программных (программно-аппаратных) средств.
В случае использования в составе Системы защиты информации средств криптографической защиты информации (СКЗИ) Исполнитель должен обладать лицензией на выполнение работ, связанных с СКЗИ, и разработать предложения по выполнению требований Приказа ФАПСИ России от 13.06.2001 г. № 152.
В случае использования внешних по отношению к системе терминалов (автоматизированных рабочих мест, терминалов самообслуживания) Исполнитель должен разработать предложения по их настройке и размещению для обеспечения требуемого уровня обеспечения информационной безопасности.
При сопряжении Системы с другими информационными системами Заказчика Исполнитель должен дать предложения по организации защищенного информационного взаимодействия.
Исполнитель должен дать предложения по численности, квалификации и режиму работы обслуживающего персонала Системы защиты информации.
Исполнитель должен разработать комплект проектной и эксплуатационной документации на подсистему защиты информации в соответствии с ГОСТ 34.201-89 и РД 50-34.698-90.
Требования по сохранности информации при авариях
Сохранность информации в Системе должна быть обеспечена при возникновении следующих событий:
ошибки в работе персонала;
прерывание связи сети Интернет;
сбой программного обеспечения Системы;
отказ одиночного сервера;
отключение питания;
разрушение жестких дисков серверов.
Сохранность информации должна обеспечиваться применением технологии RAID, за счет резервного копирования и дублирование компонент Системы в двух ЦОД Заказчика.
Система должна обеспечить такой уровень сохранности информации, который позволил бы восстановить данные с минимальной потерей информации:
в случае отказа на уровне функций Системы – без потери информации;
в иных случаях отказа – восстановление данных за период не более 8 часов до возникновения аварии (из последней резервной копии).
ПО должно восстанавливать свое функционирование при корректном перезапуске аппаратных средств. Должна быть предусмотрена возможность организации автоматического и (или) ручного резервного копирования данных Системы средствами системного и базового ПО (ОС, СУБД), входящего в состав программно-технического комплекса.
Приведенные выше требования не распространяются на компоненты Системы, разработанные третьими сторонами и действительны только при соблюдении правил эксплуатации этих компонентов, включая своевременную установку обновлений, рекомендованных производителями покупного ПО.
Требования по стандартизации и унификации
Система должна использовать общероссийские классификаторы, информационные массивы, определенные законодательством Российской Федерации и влияющие на процесс проведения торгов и выбора поставщика (исполнителя, подрядчика). Система должна на регулярной основе загружать актуальные версии справочников и классификаторов с ООС (ЕИС).
При разработке Системы должно быть минимизировано использование нестандартного, нетипового ПО. При выборе применяемых ПО преимущество должно отдаваться стандартизированным решениям, т.е. решениям, уже используемым для аналогичных целей и задач на предприятиях и в организациях, аналогичных Заказчику.
Применяемые при создании Системы технические (форматы данных, протоколы передачи и прочие) и организационные (регламенты, требования, инструкции и т.п.) решения должны быть доступны и документированы в виде, достаточном для независимой (без обращения к Исполнителю) реализации третьими сторонами. Применение недокументированных или недоступных решений не допускается.
В случае применения исполнителем специфицированных, но не стандартизированных решений должно быть представлено обоснование на каждый такой случай.
Дополнительные требования
Система должна сопровождаться обучающими видеофильмами (роликами). Обучающие ролики должны быть интуитивно понятными. В роликах должны иллюстрироваться пошаговые действия для всех основных процедур размещения заказа (работы пользователей Системы). Обучающие ролики должны иметь возможность выполняться на любом рабочем месте пользователя. Обучающие ролики должны быть разработаны в соответствии с ролевой моделью, настроенной в Системе.
|
