4Требования к системе
4.1Требования к системе в целом
Требования к структуре и функционированию системы
[В этом подразделе должны быть приведены:
перечень подсистем, их назначение и основные характеристики, требования к числу уровней иерархии и степени централизации системы. Рекомендуется дополнение описания схематическим изображением логической и физической архитектуры системы;
требования к способам и средствам связи для информационного обмена между компонентами системы;
требования к характеристикам взаимосвязей создаваемой системы со смежными системами, требования к ее совместимости, в том числе указания о способах обмена информацией (автоматически, пересылкой документов, по телефону и т. п.);
требования к режимам функционирования системы;
требования по диагностированию системы;
перспективы развития, модернизации системы].
Система должна представлять собой открытую информационную систему и интегрируемую с другими информационными ресурсами.
Модули системы должны разрабатываться с учетом многоуровневой архитектуры.
Уровень представления должен быть отделен от уровня данных слоем бизнес-логики.
Рис 1. Типовая схема трёхуровневой архитектуры
Перечень подсистем, их назначение и основные характеристики
[Текущий раздел описывает логическую и физическую архитектуру системы, поэтому здесь необходимо обозначить наличие не только функциональных подсистем, но и такие элементы архитектуры, как сервера, приложения, СУБД, АРМ пользователей, библиотеки функций, запускаемые командные файлы и управляющие скрипты, входящие в состав системы. Т. е. все, что будет устанавливаться при развертывании системы или собираться при сборке в отдельные элементы/шаблоны. Элементы, входящие в состав Системы, формируют предварительный список раздела 4 Описания архитектуры.
В разделе должен быть приведен перечень функциональных и технологических подсистем.
В случае модернизации системы должны быть указаны подсистемы, которые будут затронуты модернизацией, а также вновь создаваемые подсистемы и модули.
Число функциональных подсистем должно соответствовать (не меньше) числу автоматизируемых процессов, обозначенных в назначении системы.
Группирование функциональности в самостоятельную подсистему должно производиться по следующим принципам:
программная часть подсистемы может быть выделена в отдельный элемент;
функции подсистемы относятся к одному процессу, указанному в назначении и детализированному в характеристиках объекта автоматизации;
программная часть может быть развернута на отдельном физическом устройстве, входящем в состав системы.
Среди нефункциональных подсистем могут быть выделены:
Административная подсистема (управление пользователями, управления конфигурациями, управления справочниками и классификаторами, управления задачами и процессами);
Подсистема управления информационным взаимодействием;
Подсистема информационной безопасности;
Репозиторий (управление метаданными).
Для каждой выделенной подсистемы должно быть приведено:
назначение подсистемы (обозначены подпроцессы основного процесса, процедуры и операции которых реализованы в подсистеме);
перечень АРМов, входящих в состав подсистемы с указанием ролей пользователей, для которых предназначены данные АРМы;
перечень управляющих скриптов, системных процессов (демонов и служб), самостоятельных динамических библиотек, входящих в состав модуля;
характеристики, определяющие, где должна быть развернута подсистема и при каких условиях возможно/невозможно функционирование данной подсистемы].
В состав Системы должны входить следующие функциональные и технологические подсистемы:
подсистема администрирования;
подсистема мониторинга;
подсистема управления взаимодействием;
Исполнитель на этапе предварительного проектирования должен разработать или актуализировать и согласовать с Заказчиком архитектуру решения. Архитектура решения должна быть оформлена в соответствии с документом «Шаблон описания архитектуры». Решение по архитектуре должно отвечать, в том числе, нефункциональным требованиям, предъявляемым к системе.
Подсистема Администрирования
[По каждой подсистеме должны быть приведены: назначение, состав модулей и АРМ, необходимость которых уже выявлена на момент разработки документа для ТЗ и в обязательном порядке для ЧТЗ. Помимо этого, могут быть указаны требования, касающиеся конструктивных особенностей подсистем и их основных характеристик]
Подсистема администрирования предназначена для управления пользователями, их полномочиями, общесистемными справочниками, расписаниями выполнения заданий, шаблонами, метаданными
В состав подсистемы Администрирования должны входить следующие модули:
В состав подсистемы Администрирования должны входить следующие АРМ пользователей:
Требования к способам и средствам связи для информационного обмена между компонентами системы
[В указанном разделе может быть либо типовая вставка (пример ниже), либо, если подсистемы развернуты на различных физических/виртуальных устройствах, должны быть указаны средства и технологии, обеспечивающие связь между устройствами.]
В качестве протокола взаимодействия между компонентами Системы на транспортно-сетевом уровне необходимо использовать протокол TCP/IP.
Информационное взаимодействие между компонентами системы осуществляется посредством доступа к единому хранилищу данных (СУБД).
Для организации информационного обмена между компонентами Системы должны использоваться специальные протоколы прикладного уровня.
Требования по взаимосвязям системы с внешними и со смежными системами, обеспечению ее совместимости
[В разделе обязательно должен быть определен перечень систем, с которыми обязательно должно быть обеспечено взаимодействие. В случае наличия документации, определяющей порядок взаимодействия с этими системами, в разделе должны быть приведены ссылки на эти документы. Должно быть указано:
в части какой информации (объектов, справочников) должен происходить обмен с внешними и смежными системами;
какие данные передаются;
направление передачи данных;
способ передачи данных (полностью автоматически, при участии пользователя);
требования к допустимой нагрузке на канал передачи данных.
Должно быть указано, что на этапе предварительного проектирования точный состав внешних систем должен быть определен Исполнителем на основании анализа нормативной базы и обследования объекта автоматизации (процессов автоматизируемой деятельности). При этом по результатам анализа/обследования может быть выявлена как необходимость взаимодействия, так и отсутствие такой необходимости. При выявлении необходимости взаимодействия порядок взаимодействия должен быть описан в виде перечня случаев взаимодействия и результатов взаимодействия в Отчете об обследовании объекта автоматизации и/или в соответствующих ЧТЗ.]
Требования по интеграции с АИС «Предоставления государственных и муниципальных услуг Сахалинской области в электронной форме» (АИС «ПГМУ»)
Должно быть разработано ТЗ на создание интерактивной формы в АИС «ПГМУ» в соответствии с шаблоном (Приложение 1 к настоящему ТЗ).
Взаимодействие c АИС «ПГМУ» должно осуществляться посредством веб-сервисов.
Система должна обеспечивать следующую функциональность:
формирование и отправку запросов в АИС «ПГМУ»;
предоставление данных ведомственных словарей, классификаторов и других данных, необходимых в процессе формирования Заявления на государственную услугу;
предоставление сведений об изменениях статусов обрабатываемых обращений за определенный период по запросам из АИС «ПГМУ»;
предоставление детальных сведений об обращениях по запросам из АИС «ПГМУ»;
гарантированную доставку сообщений;
регистрацию в АИС «ПГМУ» статусов оказания услуги Заявителю;
подписание ЭП всех сведений, передаваемых при взаимодействии с АИС «ПГМУ».
Требования по интеграции с ГЕО ИС.
Должна быть реализована картографическая подсистема (модуль, блок), включающая в себя следующие функциональные возможности:
Функционирование картографической подсистемы (модуль, блок) осуществляется путем взаимодействия с ГЕО ИС и организовано на принципах и с применением специального API (application programming interface) предоставляемого Государственным заказчиком, позволяющего интегрироваться и обмениваться данными с ГЕО ИС.
Картографическая подсистема должна обеспечивать функции информационного взаимодействия, в том числе:
информационное взаимодействие с ГЕО ИС для передачи и получения данных и объектов;
Получение, обработку и представление посредством веб-сервисов картографических данных ГЕО ИС
[Требования по интеграции с <�наименование АИС-3>
…]
Требования к режимам функционирования системы
[Режимы определяют порядок эксплуатации и обслуживания системы, что в свою очередь влияет на численность персонала, режимы его работы и порядок проведения плановых работ по обслуживанию системы. Выделяют штатный режим и аварийный (нештатный) режим работы. Если указан круглосуточный штатный режим работы, но при этом не предполагается круглосуточный режим работы пользователей, то это должно быть явно указано в режимах работы персонала. Для каждого режима должно быть указано, как система попадает в этот режим и как из него выходит, вручную или автоматически. Для каждого режима должны быть указаны ограничения на доступность функций системы в этом режиме. В случае автоматического перехода системы в тот или иной режим должны быть приведены ссылки на требования к диагностированию.]
Система должна функционировать в следующих режимах:
штатный режим, при котором обеспечивается выполнение задач в объеме функций, предусмотренных настоящим техническим заданием;
сервисный режим, необходимый для проведения обслуживания, реконфигурации и пополнения технических и программных средств Системы новыми компонентами;
аварийный режим работы.
В штатном режиме функционирования Система должна обеспечивать следующий режим работы: доступность функций системы в режиме — 24 часа в день, 7 дней в неделю (24х7). Круглосуточный режим работы системы не требует организации круглосуточной работы пользователей и допускает работу пользователей в соответствии со штатным расписанием.
В сервисном режиме Система должна обеспечивать возможность проведения следующих работ:
техническое обслуживание;
модернизацию аппаратно-программного комплекса;
устранение аварийных ситуаций.
Система переходит в аварийный режим при возникновении нештатной ситуации и невозможности штатной работы. В случае перехода Системы в аварийный режим, обслуживающему персоналу необходимо перевести Систему в сервисный режим в соответствии с инструкциями, изложенными в руководстве Администратора системы.
Требования по диагностированию системы
[Требования к диагностированию определяют наличие в системе встроенных средств диагностики, перечень диагностируемых аварий в работе системы, средств журналирования, предусмотренных в системе, порядок определения аварийных ситуаций внешними средствами и системами на основании данных журналов и интерфейсов взаимодействия, ошибочных действий пользователя.
В требованиях должен быть приведен перечень аварий, которые должны диагностироваться собственными средствами системы или внешними системами мониторинга и порядок реакции на факты обнаружения аварий (действия системы, допускающие формирование сообщений, переход в аварийный режим, необходимость проведения профилактических работ и работ по обслуживанию системы).
При использовании внешних систем мониторинга должны быть указаны способы настройки пробников (симптоматики) и эталонные значения, с которыми сравниваются наблюдения, и выход за которые требует реакции/действий/сигнализации.
В требованиях может быть определена необходимость создания Исполнителем специальных автоматических тестов, подтверждающих работоспособность элементов системы после модернизации отдельных компонентов системы или изменения конфигурации системы].
Необходимо обеспечить возможность передавать следующую информацию во внешние системы мониторинга и диагностики:
информацию по взаимодействию подсистем между собой;
информацию по работоспособности каждой из подсистем;
(опционально) информацию по производительности работы (время прохождения транзакций и т.п.).
Перспективы развития, модернизации системы
[Требования к развитию могут содержать краткие сведения о целевой архитектуре системы, в случае, если предусмотрено последующее развитие.
Также могут быть определены ограничения модернизации для обеспечения совместимости с платформами, смежными системами, хранилищами данных и применяемыми техническими средствами. Если ничего этого нет, то достаточно использовать формулировки, примененные ниже
Перспективы развития, модернизации системы и выполнения работ должны коррелировать с показателями назначения (п. . Показатели назначения)
Должна быть предусмотрена возможность масштабирования Системы при увеличении нагрузки на Систему, т.е. учитываться требования к увеличению нагрузки, объемов информации и числа пользователей, последующему расширению функциональности.
Прогнозные значения увеличения нагрузки на Систему в последующие 3 года функционирования Системы:
Число пользователей …;
Объем хранимой информации … .]
|
