ТЕХНИЧЕСКОЕ ЗАДАНИЕ на разработку:

Название проекта

ID:

ID сделки из CRM

Термины и определения 4

Общие сведения 5Назначение документа 5Назначение и цели выполнения работ 5Пользователи (объекта автоматизации) 7

Характеристики объекта автоматизации 7Краткие сведения об объекте автоматизации 7Текущее состояние объекта автоматизации 7

Требования к объекту автоматизации 8Требования к системе в целом 8

Требования к структуре и функционированию 8Перечень подсистем/модулей 8

Подсистема администрирования 9Подсистема хранения 10Подсистема статистики и аналитики 10

Требования по взаимосвязям с внешними системы 10Требования к режимам функционирования системы 10Требования по диагностированию системы 11

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

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

Требования к эргономике и технической эстетике 15Требования к дизайну 15Требования к верстке 15

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

Сценарий <название сценария> 15Требования к функциям подсистемы Уведомлений 16Требования к функциям подсистемы Отчетов 16Требования к функциям подсистемы Логирования 16Требования к функциям подсистемы … 17

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

Требования к информационному обеспечению 17Требования к взаимодействию с системами 17

Информационное взаимодействие между компонентами 17Информационное взаимодействие с внешними системами 18

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

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

2

Хостинг/Сервер 20

Состав и содержание работ 20Этапы реализации проекта 20

Порядок контроля и приемки системы 22Общие требования к приемке работ по этапам 22Виды, состав, объем и методы испытаний системы и ее составных частей 23Сведения о гарантийном обслуживании 23

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

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

Приложение 1. Ролевая модель 26

Приложение 2. Уведомления 27

3

1.Термины и определения

Объект автоматизации Объектом автоматизации является продолжить

Система Указать наименование системы

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

4

2.Общие сведения2.1. Назначение документа

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

Документ содержит описание объекта автоматизации и требования по его модернизации.

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

2.2. Назначение и цели выполнения работ

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

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

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

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

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

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

Основными целями развития Системы являются:● создание единого инструмента для регистрации обращений

пользователей;● обеспечение регистрации 100% обращений пользователей;● обеспечение возможности планирования времени производства работ в

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

● обеспечение информирования пользователей о проводимых работах в момент обращения;

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

5

● улучшение качества продолжить.

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

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

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

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

данных;○ синхронизация задействованных Систем в части соответствия

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

○ мониторинг выполнения бизнес-процессов обработки сообщений;○ предоставление сводной статистической отчетности по

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

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

● обработка заявок пользователей, включая:○ прием заявок от пользователей;○ обработку заявок;○ публикацию заявок в личном кабинете пользователя;○ уведомление пользователя о статусе выполнения заявки;○ маршрутизацию заявок;○ мониторинг выполнения работ по заявке;

● развитие Системы, включая:○ развитие Системы в соответствии с требованиями настоящего

технического задания;○ ввод в действие доработанной Системы на объектах

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

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

Таблица 1. Целевые показатели

№ п/п Целевые задачи Целевые показатели

Значения показателей по

годам

1. Развитие информационно-коммуникационной инфраструктуры

Принятые заявки от пользователей, шт.

500 000 – 2020 год

700 000 – 2021 год

6

2. Развитие информационно-коммуникационной инфраструктуры

Доля обработанных заявок от пользователей в срок, %

80% - 2020 год

95% - 2021 год

2.3. Пользователи (объекта автоматизации)

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

Пользователями Системы являются:

● указать пользователей Системы;● ….

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

Объектом автоматизации является ДЕЯТЕЛЬНОСТЬ пользователей системы. В разделе должно быть краткое описание деятельности в виде основных процедур и операций, перечень участников этой деятельности, т.е. тех, кто выполняет эти операции. В разделе следует указывать только те процессы, которые будут автоматизированы в рамках настоящего ТЗ без упоминаний об уже автоматизированных или не подлежащих автоматизации в данный момент. Уже автоматизированные процессы описываются в разделе 2.2.

Объектом автоматизации Системы являются следующие процессы:

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

пользователей;● сбор и накопление необходимых статистических данных о процессах в

системе, и формирование на основе данной информации установленных видов статистических отчетов;

● и так далее.

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

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

7

Система состоит из следующих компонентов:

● привести перечень подсистем:○ модулей;

■ компонент;● ....

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

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

На данный момент существует несколько проблем. Наиболее значимые проблемы:

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

обработку данных, что приводит к потере этих данных и невозможности их обработки;

● отсутствие учета указать чего;● и так далее.

4.Требования к объекту автоматизации4.1. Требования к системе в целом

4.1.1.Требования к структуре и функционированию

4.1.1.1. Перечень подсистем/модулей

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

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

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

● программная часть подсистемы может быть выделена в отдельный элемент;

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

8

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

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

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

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

Для каждой выделенной подсистемы должно быть приведено:

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

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

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

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

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

системами (технологическая).

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

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

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

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

● привести перечень модулей;● ….

9

Подсистема хранения

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

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

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

Подсистема статистики и аналитики

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

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

● модуль сбора статистики использования указать чего;● модуль построения отчетов;● …

4.1.1.2. Требования по взаимосвязям с внешними системы

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

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

4.1.1.3. Требования к режимам функционирования системы

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

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

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

10

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

● аварийный режим работы.

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

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

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

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

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

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

4.1.1.4. Требования по диагностированию системы

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

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

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

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

11

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

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

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

транзакций и т.п.).

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

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

В подразделе должны быть указаны:

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

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

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

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

Персонал Системы должен (может) состоять из следующих категорий:

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

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

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

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

приложений и серверов баз данных.

12

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

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

● настройка и мониторинг работоспособности средств защиты информации;

● контроль доступа к информационным ресурсам Системы;● контроль доступа к сетевым ресурсам.

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

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

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

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

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

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

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

● знание основ информационной безопасности (хранение паролей).

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

4.1.3.1. Перечень событий, при которых должна быть

обеспечена сохранность информации в системе

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

● программный сбой при операциях записи/чтения;

13

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

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

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

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

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

приведший к перезагрузке системы.

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

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

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

4.1.3.2. Требования к регламентам и объемам резервного

копирования и архивирования данных

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

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

архивной копии (архивные копии log-файлов).

Указать периодичность и очередность этих операций.

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

4.1.4.1. Требования к дизайну

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

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

Адаптивность интерфейса.

14

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

4.2. Требования к реализуемым функциям

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

4.2.1.1. Сценарий <название сценария>

Подробное описание автоматизируемого бизнес сценария.

Описывается назначение сценария.

Функции и роли участников.

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

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

Приводится схема процесса

Приводится требования к работе с контентом: поиск, фильтрация

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

Указываются дополнительные требования:

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

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

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

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

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

15

4.2.3.Требования к функциям подсистемы Отчетов

4.2.4.Требования к функциям подсистемы Логирования

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

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

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

Внесению в журнал событий подлежат:

● все события административного характера; ● сведения о произошедших ошибках в Подсистеме N;● все события, относящиеся к процессу/услуге/...

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

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

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

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

4.3. Требования к информационному обеспечению

4.3.1.Требования к взаимодействию с системами

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

16

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

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

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

Указываются в виде таблицы:

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

Информационное взаимодействие между компонентами

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

Подсистема построена на основе архитектуры с тонким клиентом (веб-браузером).

Информационное взаимодействие с внешними системами

Прикладная схема архитектуры Системы с указанием внешних систем.

Информационное взаимодействие№ Источн

икПолучат

ельТехнический

Данные (объект

Тип подключе

Метод подкл

Частота

Производител

Формат

Инициатора

Протокол

17

сервис ы) ния юченияподключени

йьность данных подкл

ючения

1 Система

Внешняя Система 1

sendSubscriptionStreamEvents

Реестр 1

синхронный

REST По событию

10 запросов в секунду

JSON Система

HTTP/JSON

2 Система

Внешняя Система 2

NService

Реестр 2

синхронный

Webservice

Раз в неделю

1 запрос в секунду

XML Внешняя Система 2

SOAP

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

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

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

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

● передачу согласованного набора данных в Система2 через предоставленный интерфейс API;

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

● получение, обработку и представление посредством веб сервисов картографических данных Система2

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

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

Интеграция с Система2 осуществляется путем вызова картографического веб-сервиса путем взаимодействия через установленный Заказчиком API по HTTP протоколу.

Реализуемые API методы:

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

разрабатываемой системы;● передача идентификатора объекта/документа в разрабатываемую

систему.

Обмен осуществляется с использованием уникального идентификатора.

18

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

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

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

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

4.3.2.1. Требования к объектам

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

В случае, если система уже есть - за основу берется текущее состояние, с учетом состояния “как должно быть”.

4.3.2.2. Требования к структуре данных

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

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

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

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

● требования к применению в системе языков программирования высокого уровня;

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

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

автоматизации) - комплекс средств описания: язык программирования, язык документации, тип нотации описания БП и т.п..

5.Хостинг/Сервер

19

6.Состав и содержание работ6.1. Этапы реализации проекта

№ этапа

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

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

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

(результат работ)Начало Конец

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

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

подписание контракта

20 дней с момента подписания контракта

1. ЧТЗ, детализирующее требования

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

2. Описание архитектуры (должно быть частью ЧТЗ)

1.2 Разработка методики приемо сдаточных испытаний (ПМИ)

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

5 дней с момента окончания предварительного проектирования

3. ПМИ (Сценарии тестирования (тест-кейсы))

1.3 Детализация работ по задачам

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

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

Подписанное Заказчиком ЧТЗ и Сценарии тестирования

2 Этап 2. Выполнение работ по ЧТЗ

2.N Выполнение работ по этапу 1-N (название этапа)

1. Программный продукт2. Руководство

администратора3. Руководство

пользователя4. Прочие документы в

зависимости от специфики проекта

3 Этап 3. Приемочные испытания (приемка заказчиком)

3.N Проведение приемочных испытаний этапа 1-N

1. Протокол проведения приемочных испытаний

2. Акт сдачи-приемки

20

работ по этапу 1-N

3.N+1

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

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

4 Этап 4. Опытно-промышленная эксплуатация

4.1 Проведение опытно-промышленной эксплуатации

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

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

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

5 Этап 5. Гарантийная поддержка

5.1 ??? 1. ???

7.Порядок контроля и приемки системы7.1. Общие требования к приемке работ по этапам

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

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

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

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

Бумажный способ подразумевает под собой следующий порядок:

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

21

Электронный способ подразумевает под собой следующий порядок:

указать способ передачи, например, передача сотруднику Заказчика ссылки на гугл документы.

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

Должны быть проведены следующие виды испытаний:

● приемочные испытания;● опытно-промышленная эксплуатация.

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

Объем и методы предварительных и приемочных испытаний должны определяться ПМИ (Программой и методикой испытаний).

7.3. Сведения о гарантийном обслуживании

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

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

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

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

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

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

22

● Кто и как должен разворачивать и настраивать систему и что для этого может быть предоставлено?

● Кто и как должен загрузить исходные данные, справочники, исторические данные?

● Кто, как и в какой последовательности должен изменить конфигурацию смежных систем и систем, выводимых из эксплуатации по итогам ввода в эксплуатацию создаваемой Системы?

● Кто и как должен разработать и утвердить нормативную документацию?● Кто и как должен подготовить пользователей и организовать

эксплуатацию системы?

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

● развертывание и предварительное конфигурирование компонентов Системы;

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

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

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

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

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

9.Требования к документированиюДокументы на Систему должны оформляться на листах формата А4 без

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

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

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

Документ «Описание архитектуры» должен содержать следующие разделы:

23

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

24

Приложение 1. Ролевая модель

25

Приложение 2. Уведомления

26