пример технического задания. Техническое задание (3). 1. 1Полное наименование работ 3 2Сокращенное наименование работ 4

• Название: 1. 1Полное наименование работ 3 2Сокращенное наименование работ 4
• Анкор: пример технического задания
• Дата: 03.09.2021
• Размер: 1.97 Mb.
• Имя файла: Техническое задание (3).docx
• Тип: Документы; #229137
• страница: 13 из 25

Требования к разработке ЧТЗ и Протоколу обработки заявки на выполнение работ по развитию Системы

В рамках выполнения работ Подготовительного этапа Заказчик направляет Подрядчику заявку на выполнение работ по развитию Системы, согласованную Пользователем. Подрядчик должен предоставить Заказчику с официальным сопроводительным письмом разработанный Протокол обработки заявки на выполнение работ по развитию Системы с приложением расчета стоимости реализации решения (Приложение Д к ТЗ) и ЧТЗ, согласованные Пользователем (Функциональным заказчиком), вместе с отчетной документацией по Подготовительному этапу. Выполнение работ по заявке на выполнение работ по развитию Системы начинается с момента начала 1 (первого) отчетного периода Основного этапа Контракта.

В рамках выполнения работ Основного этапа Контракта, после получения заявки на выполнение работ по развитию Системы от Заказчика, согласованной Пользователем, Подрядчик должен разработать и согласовать с Пользователем (Функциональным заказчиком) Протокол обработки заявки на выполнение работ по развитию Системы (Приложение Д к ТЗ) с приложением расчета стоимости реализации решения и ЧТЗ. Подрядчик должен предоставить с официальным сопроводительным письмом вышеуказанные документы не позднее 15 (пятнадцати) календарных дней с даты получения заявки на выполнение работ по развитию Системы. ЧТЗ должно быть подготовлено в соответствии с требованиями заявки на выполнение работ по развитию системы, ТЗ и должно содержать:

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

Расчет стоимости реализации решения должен быть подготовлен с учетом распоряжения Департамента экономической политики и развития города Москвы и Департамента информационных технологий города Москвы от 28 февраля 2018 г. № 64-16-89/18/3-Р.

Расчет стоимости реализации решения должен включать в себя:

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

Подрядчик приступает к работам по заявке на выполнение работ по развитию Системы только после согласования с Пользователем (Функциональным заказчиком) и утверждения Заказчиком соответствующего Протокола обработки заявки на выполнение работ по развитию Системы с приложением расчета стоимости реализации решения и ЧТЗ. Стоимость работ определяется как произведение стоимости 1 (одного) человеко-месяца, определенной в Приложении Г к ТЗ, и количества человеко-месяцев, требующихся для выполнения работ по развитию Системы по соответствующей заявки на выполнение работ по развитию Системы, рассчитанных согласно распоряжению Департамента экономической политики и развития города Москвы и Департамента информационных технологий города Москвы от 28 февраля 2018 г. № 64-16-89/18/3-Р.

3. Требования к видам обеспечения

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

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

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

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

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

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

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

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

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

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

Факты информационного обмена должны фиксироваться в соответствующем журнале.

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

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

В ЧТЗ должна быть определена необходимость использования централизованных справочных данных для организации межсистемного взаимодействия при получении данных, входящих в состав справочников, указанных в Приложении 4 «Навигатор справочников» к стандарту ведения данных.

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

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

4. Назначение справочников и классификаторов и информации, хранящейся в них

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

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

Объем и состав информации, получаемой из классификаторов, должны быть описаны в документе «Описание информационного обеспечения».

Необходимость создания и порядок управления дополнительными классификаторами и справочниками должны быть приведены в соответствующих разделах ЧТЗ на Систему и описаны в документе «Описание информационного обеспечения».

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

5. Требования по применению систем управления базами данных

Для хранения данных в Системе должны использоваться реляционные (объектно-реляционные) и не реляционные базы данных, обеспечивающие реализацию встроенных механизмов построения индексов и контроля целостности данных.

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

Общие требования к используемой реализации СУБД:

• 
  поддержка реляционной, объектно-реляционной или не реляционной модели базы данных;
  
• 
  поддержка технологии клиент-сервер;
  
• 
  поддержка многопроцессорной архитектуры;
  
• 
  наличие средств создания индексов и кластеров данных;
  
• 
  автоматическое восстановление базы данных;
  
• 
  совместимость с различными операционными системами серверов БД;
  
• 
  поддержка сетевых протоколов TCP/IP;
  
• 
  наличие графических средств администрирования;
  
• 
  возможность контроля доступа к данным;
  
• 
  централизованное управление учетными записями пользователей Системы;
  
• 
  оптимизация запросов.
  

6. Требования к структуре процесса сбора, обработки, передачи данных в системе и представлению данных

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

В ЧТЗ должна быть определена необходимость соответствия требованиям, описанными в Приложении № 1 «Навигатор атрибутов» к стандарту ведения данных. Данные требования относятся к тем информационным объектам, которые описаны в стандарте ведения данных и создаются, изменяются или удаляются в Системе (далее – информационные объекты).

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

С целью контроля соответствия обрабатываемых в Системе данных стандарту ведения данных должен быть реализован механизм предоставления Оператору данных наборов атрибутов, описанных в Приложении № 1 «Навигатор атрибутов» к стандарту ведения данных, без привязки к экземплярам сущностей, хранящихся и обрабатываемых в Системе. Предоставление указанных данных Оператору данных должно быть обеспечено на регулярной основе, в соответствии с форматом, заданным в стандарте ведения данных, и должно предусматривать инкрементальный режим предоставления данных и режим предоставления полного набора данных по информационным объектам.

7. Требования к защите данных от разрушений при авариях и сбоях в электропитании системы

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

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

8. Требования к контролю, хранению, обновлению и восстановлению данных

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

9. Требования к процедуре придания юридической силы документам, продуцируемым техническими средствами системы

Придание документам, продуцируемым Системой, юридической силы должно производиться в соответствии с рекомендациями ГОСТ 6.10.4-84.

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

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

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

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

Языки разработки программного обеспечения, которые должны использоваться при развитии Системы: основной ‒ Java, вспомогательный ‒ JavaScript.

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

В составе программного обеспечения Системы должно содержаться общесистемное и прикладное программное обеспечение (ППО).

Общесистемное программное обеспечение должно включать в себя:

• 
  операционную систему для серверной части Системы на базе Linux (Red Hat Enterprise Linux 7 и выше);
  
• 
  операционную систему рабочих станций пользователей Системы (клиентской части) на базе Microsoft Windows 7 и выше;
  
• 
  веб-сервер Apache версии не ниже 2.2.16 или веб-сервер;
  
• 
  СУБД Oracle 11.2.0.4 Enterprise Edition;
  
• 
  необходимые программные библиотеки;
  
• 
  системные утилиты и другое необходимое программное обеспечение.
  

Разрабатываемое ППО должно отвечать следующим требованиям:

• 
  информационная совместимость в пределах требований к информационному обмену;
  
• 
  совместимость программных продуктов в части используемых технических средств, системного программного обеспечения и общесистемной инфраструктуры в пределах требований к техническому обеспечению;
  
• 
  наличие эксплуатационной документации на русском языке.
  
• 
  Клиентская часть Системы должна функционировать в интернет-браузерах Google Chrome для Windows, Mozilla Firefox для Windows, Opera для Windows в последних на момент проведения испытаний версиях.
  
• 
  При использовании других интернет-браузеров допускается ухудшение функций Системы и ее внешнего вида.
  
• 
  В части мобильных приложений должен использоваться Android OS версии не ниже 5.
  

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

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

Таблица 20. Рекомендуемое ППО

Наименование	Назначение
Интеграционные компоненты
WSO2 EI	Реализация сервисов
WSDL или Swager	Описание сервисов
WSO2 API Manager	Публикация сервисов
Очереди сообщений
Apache Kafka	Диспетчер сообщений
Расчетная логика
Java/Scala	Реализация бизнес-логики
Apache Spark	Поддержка набора библиотек
Хранилище данных
Apache Hadoop HDFS	Хранение нереляционных данных
Apache Hive	Реляционная составляющая
Apache HBase	Колоночная СУБД
PostgreSQL	Реляционная СУБД
Apache ignite	База данных реального времени
Статический контент
Nginx	Маршрутизация и проксирование
Сервер приложений
Tomcat	Сервер приложений Java

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

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

2. Требования к качеству программных средств, способам его обеспечения и контроля

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

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

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

5. Требования к техническому обеспечению

Технические средства, необходимые для размещения разрабатываемого решения, должны быть предоставлены Заказчиком.

Состав, схема подключения и конфигурации технических средств должны быть приведены в документе «Описание архитектуры системы».

Архитектура Системы должна быть разработана в соответствии с трехуровневой клиент-серверной архитектурой и состоять из следующих уровней:

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

Уровень презентаций должен быть разработан в соответствии с принципами архитектуры «тонкого клиента».

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

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

7. Требования к организационному и методическому обеспечению

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

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

   1. Необходимые линии и каналы связи

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

2. Среда передачи

Связь между компонентами развиваемой Системы должна осуществляться с использованием локальной сети и сети Интернет.

3. Технические параметры каналов связи

Требования к техническим параметрам каналов связи не предъявляются.

4. Пропускная способность

Пропускная способность каналов связи должна быть не ниже 10 Мбит/с.

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

Требования к организации новых каналов связи не предъявляются.

9. Требования к другим видам обеспечения

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