2. Техническое задание к лицензионному договору

Приложение №2
к Лицензионному договору №___ от ____.________.20____ г.
ТЕХНИЧЕСКОЕ ЗАДАНИЕ
Требования, устанавливаемые к качеству, техническим характеристикам и
результатам работы Программного обеспечения. Требования к прикладному
программному модулю
1
1.1
Назначение прикладного программного модуля
Прикладной программный модуль (далее Модуль) предназначен для размещения
функциональных подсистем автоматизированной системы паспортизации объектов и
подтверждения объемов оказанных услуг (далее Система).
1.2
Требования к функциональным возможностям прикладного программного
модуля
Прикладной программный модуль должен предоставлять следующие базовые функции:




организация интерфейса пользователя в виде «одного окна»;
визуализация информации в интерактивном формате представления;
ролевая модель;
обеспечение информационной безопасности.
1.2.1 Требования к функционалу «Организация интерфейса пользователя в виде
«одного окна»»
Пользователю должно быть предоставлено информационно-управляющее поле в режиме
«одного окна», обеспечивающее:
 предоставление всех необходимых для работы пользовательских интерфейсов в
соответствии с предоставленными правами доступа;
 формирование информационного контекста для автоматизации текущего сценария
работы.
Информационно-управляющее поле пользователя автоматически должно адаптироваться
под выполняемый сценарий работы, заложенный в функциональных подсистемах Модуля, в
соответствии с ролевой моделью.
Модуль должен предоставлять пользователю единые правила работы с
функциональными подсистемами, такие как:




ввод логина и пароля однократно при работе с несколькими подсистемами;
выполнение поиска информации в Системе;
переключение на требуемые формы подсистем Модуля;
выдача «подсказок» на этапах выполнения сценариев, требующих принятия
решений и т.д.
1
1.2.2 Требования к функционалу «Визуализация информации в интерактивном
формате представления»
Визуализация информации в Системе должна быть обеспечена в формате интерактивных
графиков, таблиц и диаграмм. Ключевые показатели предоставления услуг должны быть
визуализированы на основе данных, предоставляемых подсистемами Модуля.
1.2.3 Требования к функционалу «Ролевая модель»
Под ролевой моделью понимается разделение пользователей на группы, имеющие в силу
должностных обязанностей или иных интересов схожий набор обязанностей и связанных с
ними сценариев работы в Системе.
Поддержка ролевой модели должна позволять в зависимости от роли адаптировать
информационно-управляющее поле, а именно:
 предоставлять только необходимую информацию, имеющую отношение к задачам
пользователя;
 разграничить доступ к интерфейсам подсистем Модуля в соответствии с правами
роли;
 изменять поведение Системы (внешний вид интерфейса и реакцию на события) в
соответствии со сценариями работы;
 разграничить доступ к сценариям работы.
1.2.4 Требования к функционалу «Обеспечение информационной безопасности»
Информационная безопасность на уровне Модуля должна обеспечиваться следующими
основными подсистемами:
 подсистема управления доступом – управление доступом в Систему, к программам
и функциям подсистем Модуля, к данным;
 подсистема регистрации и учета событий – протоколирование и аудит событий
Системы;
 подсистема шифрования хранимых данных и шифрования передаваемых данных.
Управление доступом должно осуществляться путѐм использования следующих
технологий, механизмов и моделей:
 модели безопасности на уровне операционной системы;
 разграничение доступа к данным и функциям Модуля на основе ролевой модели;
 систем централизованного управления идентификацией пользователей.
В процессе работы пользователям должна быть обеспечена возможность однократной
аутентификации для доступа к предоставленным ему в соответствии с ролью функциональным
подсистемам.
На уровне Модуля должна осуществляться регистрация и учет следующих событий:




вход (выход) в Систему;
запуск (завершение) программ и сценариев;
доступ к данным (чтение, добавление, удаление, изменение);
изменение настроек Системы.
Шифрование на уровне хранения данных должно осуществляться стандартными
средствами СУБД.
2
1.3
Перечень функциональных подсистем Модуля
Для реализации основных функций Модуль должен обеспечивать возможность
размещения следующих функциональных подсистем:











подсистема работы с договорами;
подсистема работы с объектами (зданиями и сооружениями);
подсистема работы с паспортами объектов (зданий и сооружений);
подсистема согласования паспортов объектов (зданий и сооружений);
подсистема расчета начислений за оказанные услуги;
подсистема согласования актов оказанных услуг;
подсистема работы со счетами по актам оказанных услуг;
подсистема аналитики и отчетности;
подсистема работы с нормативно-справочной информацией;
подсистема применения электронной подписи;
подсистема настройки пользовательского доступа.
1.3.1 Подсистема работы с договорами
Подсистема работы с договорами предназначена для обработки и хранения информации
о контрагентах и заключаемых договорах, информации по точкам поставки, договорным
величинам оказания услуг, приборам учета и расхода, согласно акта снятия показаний,
формирования печатной формы договора и приложений к нему.
1.3.2 Подсистема работы с объектами (зданиями и сооружениями)
Подсистема работы с объектами (зданиями и сооружениями) предназначена для
обработки и хранения информации о зданиях и сооружениях, в том числе технических и
теплотехнических характеристик.
1.3.3 Подсистема работы с паспортами объектов (зданий и сооружений)
Подсистема работы с паспортами объектов (зданий и сооружений) предназначена для
обработки и хранения информации о технических характеристиках объектов, а также
прилегающей территории, сведений о площадях объектов, в том числе уборочных, сведений по
общей степени износа на определенную дату, ведений о конструктивных элементах
здания/сооружения, инженерных системах.
1.3.4 Подсистема согласования паспортов объектов (зданий и сооружений)
Подсистема согласования паспортов объектов (зданий и сооружений) предназначена для
реализации изменения статусных состояний паспортов объектов (зданий и сооружений) в
рамках взаимодействия участников информационного обмена в Системе.
1.3.5 Подсистема расчета начислений за оказанные услуги
Подсистема расчета начислений за оказанные услуги предназначена для обработки и
хранения информации для автоматического выполнения расчетов по ежемесячному
начислению за объемы фактически оказанных услуг.
3
1.3.6 Подсистема согласования актов оказанных услуг
Подсистема согласования актов оказанных услуг предназначена для реализации
изменения статусных состояний актов оказанных услуг в рамках взаимодействия участников
информационного обмена в Системе.
1.3.7 Подсистема работы со счетами по актам оказанных услуг
Подсистема работы со счетами по актам оказанных услуг предназначена для
формирования счетов, счетов-фактур и актов оказанных услуг для взаимодействия с
контрагентами согласно договорам.
1.3.8 Подсистема аналитики и отчетности
Подсистема аналитики и отчетности предназначена для формирования аналитической
отчетности и получение сводной информации об объемах оказанных услуг по договорам.
1.3.9 Подсистема работы с нормативно-справочной информацией
Подсистема работы с нормативно-справочной информацией для обработки и хранения
справочной информации, необходимой для функционирования Системы.
1.3.10 Подсистема применения электронной подписи
Подсистема применения электронной подписи предназначена для реализации
возможности подписания электронных документов с использованием квалифицированной
электронной подписи.
1.3.11 Подсистема настройки пользовательского доступа
Подсистема настройки пользовательского доступа предназначена для реализации
возможности разграничения доступа пользователей к программам и функциям подсистем
Модуля.
4
2
Требования, установленные к качеству, техническим характеристикам и
результатам работы Программного обеспечения. Требования, предъявляемые к
общесистемному программному обеспечению (далее - ОПО).
- общесистемное программное обеспечение должно быть встроенным решением для ПО;
- ОПО должно поддерживать работу с многомерными данными;
- в ОПО должны присутствовать объектный или реляционный доступ к данным;
- системы управления базами данных должны обеспечивать транзакционные механизмы,
обеспечивать
декларативную
ссылочную
целостность,
позволять
наращивать
производительность путем увеличения вычислительной мощности без изменений на
прикладном уровне;
- СУБД должна быть объектно-ориентированной базой данных, с возможностью хранения
данных и методов их обработки. Должна обеспечиваться возможность хранения и обработки
мультимедийных данных.
- СУБД должна иметь возможность независимости хранения данных от способа их
представления. В рамках данной архитектуры должно быть единое описание объектов и таблиц,
отображаемых непосредственно в многомерные структуры ядра базы данных, ориентированных
на обработку транзакций;
- в СУБД должна быть реализована встроенная технология создания динамических webприложений;
- в СУБД должна быть реализована встроенная технология обработки транзакций и
разрешения конфликтов, с возможностью блокировки данных на логическом уровне.
- СУБД должны обеспечивать поддержку объектной модели всех основных концепций
объектной технологии:

Наследование – объектная модель должна позволять наследовать классы от
произвольного количества родительских классов.

Полиморфизм- объектная модель должна позволять создавать приложения целиком и
полностью независимыми от внутренней реализации методов объекта.

Инкапсуляция – объектная модель должна обеспечивать сокрытие отдельных деталей
внутреннего устройства классов от внешних по отношению к нему объектов или
пользователей. Разделение интерфейсной части класса и конкретной реализации.
Интерфейсная часть необходима для взаимодействия с любыми другими объектами.
5

Хранимость – система должна поддерживать несколько видов хранения объектов:
автоматическое хранение в многомерной базе данных; хранение в любых структурах,
определенных пользователем; хранение в таблицах внешних реляционных баз
данных, доступных через интеграционный шлюз.
- СУБД должна поддерживать структурированный язык запросов SQL для обеспечения
запросов.
- СУБД должна поддерживать возможность автоматического преобразования реляционных
таблиц в классы объектов.
6
3
Требования к адаптации и доработке прикладного программного модуля для
нужд Заказчика
Функционал подсистем Модуля должен быть адаптирован и доработан для нужд
Заказчика.
3.1. Требования к доработке подсистемы работы с договорами
Подсистема должна обеспечивать возможность выполнения следующих функций:
1. Регистрация государственных контрактов.
В подсистеме должна быть реализована возможность зарегистрировать новый
государственный контракт с Минобороны России путем создания регистрационной карточки
государственного контракта, перечень реквизитов которой должен быть согласован с
Заказчиком.
2. Хранение государственных контрактов с приложениями.
В подсистеме должна быть реализована возможность загрузки, хранения и просмотра
файлов, содержащих сканированные образы оригиналов государственных контрактов с
Минобороны России, приложений к ним и дополнительных соглашений.
3. Регистрация изменения статуса государственного контракта в процессе его жизненного
цикла.
В подсистеме должна быть реализована возможность регистрации изменения статуса
государственного контракта с Минобороны России.
Список статусов и алгоритм перехода состояний государственного контракта должны
быть согласованы с Заказчиком.
4. Архивное хранение государственного контракта.
После присвоения государственному контракту статуса «Архив» Система должна
автоматически перемещать карточку государственного контракта и все сопутствующие
документы в электронный архив. Удаление из электронного архива должно происходить с
помощью регламентной процедуры. При удалении карточки государственного контракта
автоматически должны удаляться все прикреплѐнные к ней файлы документов.
3.2.Требования к доработке подсистемы работы
сооружениями)
с объектами (зданиями и
Подсистема должна обеспечивать возможность выполнения следующих функций:
1. Ведение реестра военных городков.
В подсистеме должна быть реализована возможность ведения реестра военных городков
с привязкой к зоне ответственности соответствующей организации районного представителя
государственного заказчика.
2. Работа с паспортами военных городков.
В подсистеме должна быть реализована возможность ведения паспорта военного городка
по разделам, в том числе возможность прикрепления, хранения и просмотра файлов
сканированных образов документов в формате JPEG, PDF.
3. Ведение сведений об объектах военных городков, в том числе технических и
теплотехнических.
В подсистеме должна быть реализована возможность ведения сведений об объектах
военных городов путем заполнения регистрационной карточки. Требования к составу сведений
регистрационной карточки должны быть согласованы с Заказчиком.
Система должна позволять вести следующие теплотехнические характеристики объектов
военного городка:
 информация по режимам потребления тепловой энергии объектов военных
городков;
 информация о расчетной температуре воздуха в отапливаемом здании;
7
 информация о характеристиках потребления горячего водоснабжения, пара,
использования вентиляции (нормативные).
3.3. Требования к доработке подсистемы работы с паспортами объектов (зданий и
сооружений)
Подсистема должна обеспечивать возможность выполнения следующих функций:
1. Формирование печатной формы паспорта объекта военного городка.
В соответствии с внесенными данными по объектам военных городков, Система должна
обеспечить возможность формирования печатной формы паспорта объекта военного городка.
Формат печатной формы паспорта объекта военного городка должен быть согласован с
Заказчиком.
2. Формирование печатной формы разделов паспорта военного городка.
В соответствии с внесенными данными по военным городкам и объектам военных
городков, Система должна обеспечить возможность формирования печатной формы паспорта
военного городка по разделам. Форматы печатных форм разделов паспорта военного городка
должны быть согласованы с Заказчиком.
3. Хранение паспортов военных городков.
В подсистеме должна быть реализована возможность прикрепления, хранения и
просмотра файлов сканированных образов подписанных паспортов военных городков в
формате JPEG, PDF.
3.4. Требования к доработке подсистемы согласования паспортов объектов (зданий
и сооружений)
Подсистема должна обеспечивать возможность выполнения следующих функций:
1. Согласование
разделов
паспорта
военного
городка
между
участниками
информационного обмена внутри системы.
В подсистеме должна быть реализована возможность регистрации изменения статуса
разделов паспорта военного городка в рамках взаимодействия участников информационного
обмена в Системе.
Список статусов и алгоритм перехода состояний разделов паспорта военного городка
должны быть согласованы с Заказчиком.
3.5. Требования к доработке подсистемы расчета начислений за оказанные слуги
Подсистема должна обеспечивать возможность выполнения следующих функций:
1. Ведение сведений по справкам о фактически оказанных услугах.
В подсистеме должна быть реализована возможность ежемесячного учета сведений по
Справкам о фактически оказанных услугах, в том числе показаний приборов учета, изменения
нормативных показателей потребления воды, пара и использования вентиляции на объектах
военных городков за расчетный период, а также сведений о нарушениях оказанных услуг,
согласно актам недопоставки.
2. Формирование печатной формы справки о фактически оказанных услугах.
В подсистеме должна быть реализована возможность формирования печатной формы
для заполнения Справки о фактически оказанных услугах на основании ежемесячных сведений
о фактическом потреблении тепловой энергии объектами военного городка.
Форма для заполнения Справки о фактически оказанных услугах должна включать
сведения об объектах военных городков, установленных приборов учета.
Формат печатной формы для заполнения Справки о фактически оказанных услугах
должен быть согласован с Заказчиком.
3. Хранение Справок о фактически оказанных услугах.
8
В подсистеме должна быть возможность загрузки и хранения файлов, содержащих
сканированные образы заполненных Справок о фактически оказанных услугах, подписанных
ответственными лицами в формате JPEG, PDF.
3.6. Требования к доработке подсистемы согласования актов оказанных услуг
Подсистема должна обеспечивать возможность выполнения следующих функций:
1. Согласование первичных актов оказанных услуг.
В подсистеме должна быть реализована возможность регистрации изменения статуса
первичных актов оказанных услуг в рамках взаимодействия участников информационного
обмена в Системе.
Список статусов и алгоритм перехода состояний первичных актов оказанных услуг
должны быть согласованы с Заказчиком.
2. Согласование сводных актов оказанных услуг Минобороны России.
В подсистеме должна быть реализована возможность регистрации изменения статуса
сводных актов оказанных услуг в рамках взаимодействия участников информационного обмена
в Системе.
Список статусов и алгоритм перехода состояний сводных актов оказанных услуг должны
быть согласованы с Заказчиком.
3.7. Требования к доработке подсистемы работы со счетами и актами оказанных
услуг
Подсистема должна обеспечивать возможность выполнения следующих функций:
1. Хранение подписанных первичных и сводных актов оказанных услуг.
В подсистеме должна быть реализована возможность загрузки, хранения и просмотра
файлов, содержащих сканированные образы оригиналов первичных и сводных актов оказанных
услуг в формате JPEG, PDF.
2. Формирование счетов, счетов-фактур по каждому согласованному сводному акту
оказанных услуг.
В подсистеме должна быть реализована возможность формирования и выставления счета
за оказанные услуги в соответствующем расчетном периоде по каждому согласованному
сводному акту оказанных услуг.
В подсистеме должна быть реализована возможность формирования печатной формы
следующих документов по шаблону:
 счет;
 счет-фактура;
 акт оказанных услуг.
Шаблоны документов должны быть согласованы с Заказчиком.
3. Формирование заявки на оплату по согласованным счетам и сводным актам оказанных
услуг.
В подсистеме должна быть реализована возможность формирования заявки на оплату по
согласованным счетам и сводным актам оказанных услуг.
Формат заявки на оплату должен быть уточнен и согласован с Заказчиком.
3.8. Требования к доработке подсистемы аналитики и отчетности
Подсистема должна обеспечивать возможность выполнения следующих функций:
1. Формирование отчетности об исполнении государственных контрактов.
Отчет должен содержать сведения об объемах оказанных услуг по государственным
контрактам Минобороны России в натуральных и стоимостных выражениях в разрезе
расчетных периодов, первичных и сводных актов оказанных услуг.
9
Формат отчета должен быть уточнен и согласован с Заказчиком.
3.9. Требования к доработке подсистемы работы с нормативно-справочной
информацией
Подсистема должна обеспечивать возможность выполнения следующих функций:
1. Ведение справочника доверенных лиц районных представителей государственного
заказчика.
В подсистеме должна быть реализована возможность ведения сведений о действующих
доверенностях районных представителей государственного заказчика с указанием фамилии
имени отчества руководителей районных представителей государственного заказчика и периода
действия доверенности, обосновывающей подписание паспортов военных городков и
первичных актов оказанных услуг.
Ввод сведений о доверенностях районных представителей государственного заказчика
должен быть реализован путем заполнения регистрационной карточки доверенности.
Требования к составу сведений регистрационной карточки должны быть определены и
согласованы с Заказчиком.
2. Ведение справочника доверенных лиц окружных представителей государственного
заказчика.
В подсистеме должна быть реализована возможность ведения сведений о действующих
доверенностях окружных представителей государственного заказчика с указанием фамилии
имени отчества руководителей окружных представителей государственного заказчика и
периода действия доверенности, обосновывающей подписание сводных актов оказанных услуг.
Ввод сведений о доверенностях окружных представителей государственного заказчика
должен быть реализован путем заполнения регистрационной карточки доверенности.
Требования к составу сведений регистрационной карточки должны быть определены и
согласованы с Заказчиком.
3.10. Требования к доработке подсистемы применения электронной подписи
В подсистеме должна быть реализована возможность подписания электронных
документов с использованием только квалифицированной электронной подписи. Форма
квалифицированного сертификата ключа проверки электронной подписи должна
соответствовать требованиям Приказа федеральной службы безопасности РФ от 27.12.2011г. №
795 «Об утверждении требований к форме квалифицированного сертификата ключа проверки
электронной подписи».
На стороне пользователя должна быть обеспечена возможность подписать электронный
документ выбранным сертификатом. Размер подписываемого файла может достигать сотен
мегабайт.
Подсистема должна обеспечивать возможность выполнения следующих функций:
1. Подписание паспорта военного городка в электронной форме с использованием
электронной подписи.
В подсистеме должна быть реализована возможность подписания заранее
сформированного файла печатной формы паспорта военного городка в целом и каждого его
раздела отдельно с использованием электронной подписи.
2. Загрузка и хранение подписанного файла паспорта военного городка.
В подсистеме должна быть реализована возможность загрузки и хранения подписанного
электронной подписью файла печатной формы паспорта военного городка.
3. Подписание первичных актов оказанных услуг в электронной форме с использованием
электронной подписи.
В подсистеме должна быть реализована возможность подписания заранее
сформированного файла печатной формы первичного акта оказанных услуг с использованием
электронной подписи.
4. Загрузка и хранение подписанного файла первичного акта оказанных услуг.
10
В подсистеме должна быть реализована возможность загрузки и хранения подписанного
электронной подписью файла первичного акта оказанных услуг.
5. Подписание сводных актов оказанных услуг в электронной форме с использованием
электронной подписи.
В подсистеме должна быть реализована возможность подписания заранее
сформированного файла печатной формы сводного акта оказанных услуг с использованием
электронной подписи.
6. Загрузка и хранение подписанного файла сводного акта оказанных услуг.
В подсистеме должна быть реализована возможность загрузки и хранения подписанного
электронной подписью файла сводного акта оказанных услуг.
3.11. Требования к доработке подсистемы настройки пользовательского доступа
Подсистема должна обеспечивать возможность выполнения следующих функций:
1. Настройка пользовательской роли районных представителей государственного
заказчика.
В подсистеме должна быть реализована возможность настройки автоматизированного
рабочего места пользовательской роли для сотрудников районных представителей
государственного заказчика. Параметры для настройки должны быть согласованы с
Заказчиком.
2. Настройка пользовательской роли окружных представителей государственного
заказчика.
В подсистеме должна быть реализована возможность настройки автоматизированного
рабочего места пользовательской роли для сотрудников окружных представителей
государственного заказчика. Параметры для настройки должны быть согласованы с
Заказчиком.
3. Настройка пользовательской роли Департамента эксплуатационного содержания и
обеспечения коммунальными услугами воинских частей и организаций Минобороны
России.
В подсистеме должна быть реализована возможность настройки автоматизированного
рабочего места пользовательской роли для сотрудников Департамента эксплуатационного
содержания и обеспечения коммунальными услугами воинских частей и организаций
Минобороны России. Параметры для настройки должны быть согласованы с Заказчиком.
11
4
№
п/п
Виды работ и сроки их выполнения
Ответственная
сторона
Вид работ
Срок
(календарных
дней)
1 этап. Предоставление права использования
Предоставление на условиях простой
Исполнитель
В течение 5 дней с
(неисключительной) лицензии права
даты подписания
использования функционального прикладного
Лицензионного
модуля для размещения автоматизированной
договора
системы паспортизации объектов и
подтверждения объемов оказанных услуг
Подписание акта приема-передачи права
Исполнитель,
использования
Заказчик
2 этап. Формирование требований на доработку и адаптацию Модуля
Согласование перечня участников
Исполнитель,
Не более 15 дней с
Заказчик
даты начала
реализации
Согласование плана-графика выполнения работ, Исполнитель,
проекта
регламентов взаимодействия всех участников
Заказчик
Проведение демонстрации прототипа Модуля
Исполнитель
Формирование и согласование перечня доработок Исполнитель,
Модуля
Заказчик
3 этап. Доработка и адаптация Модуля под нужды Заказчика
Доработка и настройка функционала подсистем
Исполнитель
Не более 45 дней с
Модуля в соответствии с согласованным
даты начала
перечнем требований
реализации
проекта
Разработка и предоставление рабочей
Исполнитель
документации
Проведение приемочных испытаний Системы
Заказчик,
Исполнитель
Подписание Акта выполненных работ
Заказчик,
Исполнитель
12
Результаты выполненных работ
5
По окончанию этапов работ по проекту должны быть представлены следующие
документы:
1 этап. Предоставление права использования
 Акт приема-передачи права использования.
2 этап. Формирование требований на доработку и адаптацию Модуля





Согласованный перечень участников;
Согласованный план-график выполнения работ;
Согласованный регламент взаимодействия всех участников;
Протокол проведения демонстрации прототипа Модуля;
Согласованный перечень доработок Модуля.
3 этап. Доработка и адаптация Модуля под нужды Заказчика




Руководство пользователя (администратор);
Программа и методики проведения испытаний;
Протокол и акт о проведении приемочных испытаний Системы;
Акт выполненных работ.
От имени Лицензиара
Директор
___________________ /___________/
М.П.
От имени Лицензиата
___________________ /___________/
М.П
13