ShariX Open Docs

Эта страница только для чтения. Вы можете посмотреть её исходный текст, но не можете его изменить. Сообщите администратору, если считаете, что это неправильно.
====== Рекомендации по подготовке технического задания для разработки сервисов на основе Интернета Вещей ======

===== 1. Общие положения =====

Данные рекомендации по подготовке технического задания (далее – Рекомендации) подготовлены в целях систематизации и обеспечения единого подхода к подготовке документации для разработки сервисов на основе Интернета Вещей для компании ООО “ШЭРИКС”.
Рекомендации предназначены для заказчиков, осуществляющих разработку сервисов для компании ООО “ШЭРИКС”.

Настоящие рекомендации разработаны на основании следующих документах:
  - ГОСТ 34.602-89;
  - ГОСТ 19.201-78;
  - руководство по созданию продуктов ООО “ШЭРИКС”.
Составленные рекомендации содержат в себе:
  - структуру технического задания;
  - конкретизацию требований к уровню безопасности создаваемых сервисов;
  - закрепление перечня рекомендованного программного обеспечения, используемого для разработки сервисов на основе Интернета Вещей в ООО “ШЭРИКС”.
===== 2. Общие принципы составления технического задания =====

Под техническим заданием в данных рекомендациях понимается полный перечень требований, условий, целей, задач, поставленных заказчиком перед участниками закупки в письменном виде, изложенных в документации. Техническое задание должно являться точным описанием всех требований и нужд заказчика.
При составлении технического задания заказчику необходимо создать описание конечного продукта, описать цель с которой данный продукт создается, описать требования к функционалу и желаемые действия при получении конечного продукта.
Также при разработке технического задания рекомендуется придерживаться представленных ниже правил.
  - Рациональность при составлении требований к заказу. Требования к исполнителю должны быть умеренными, не стоит предъявлять детальный список задач сверх необходимого для реализации конечного продукта – это не только затягивает процесс подготовки (т. е. разработки технического задания), но также ограничивает количество потенциальных исполнителей, что приводит к еще большей задержке в процессе производства продукта. Однако отсутствие понятных и необходимых требований приводит к затягиванию производства, снижению качества финального продукта и в последствии долгих доработок.
  - Конкретность при составлении технического задания. Финальный продукт должен быть понятно и конкретно описан, задачи должны иметь логическое обоснование. Исполнитель должен однозначно определить предъявляемый список требований, понять сколько у него займет время на выполнение и понять сможет ли он полностью удовлетворить потребность заказчика.
Таким образом, требования к исполнителю должны быть понятными, отражать требования заказчика в полной мере и обладать необходимым набором задач, которые действительно нужны для создания продукта.
Также следует понимать, что если все поставленные требования исполнителем были выполнены, но финальный результат не устраивает заказчика и требует доработки, исполнитель может потребовать оплату его работы и прекратить сотрудничество, что в свою очередь может затянуть процесс разработки, что дополнительно показывает необходимость правильной постановки задач и необходимость описания качества финального продукта.
Составленное техническое задание не должно противоречить ГОСТ 34.602-89 и ГОСТ 19.201-78.
===== 3. Структура технического задания =====

В данном разделе представлена структура, которой следует придерживаться при составлении ТЗ для сервисов ООО “ШЭРИКС” на основе Интернета Вещей. Структура основана на ГОСТ 34.602-89 и ГОСТ 19.201-78.
Техническое задание должно содержать представленные ниже разделы.
==== 1.	Введение ====

Краткое описание – что за система, зачем, что делает, какова ее цель существования и решаемые ею задачи. Ее целевая аудитория и краткое описание технического представления решения для целевой аудитории.
Глоссарий.
==== 2. Основания для разработки ====

Должны быть указаны причины, на основе которых ведется разработка, для кого она производится.
=== 2.1. Описание внутренних подсистем ===

Следует перечислить все системы, которые будут в проекте. Это могут быть:
  * конкретные программные и иные технологические продукты (1 продукт – 1 система, например – мобильное приложение для клиента, мобильное приложение для исполнителя, админка для исполнителя и так далее);
  * внутренние решения (например – почтовый сервер, система эшелонированных бэкапов, система внутреннего документооборота);
  * системы для обеспечения законной деятельности (например – система отправки отчетности в госорганы, платежная система, виртуальный кассовый принтер);
  * инфраструктурные решения (системы внутри офиса, серверной и так далее).
К каждой выделенной системе необходимо дать короткое описание, которое содержит следующую информацию:
  * название системы;
  * тип системы (внутренняя или есть взаимодействие с внешними системами);
  * программные продукты, имеющие отношение к реализации системы, предполагаемые языки программирования в случае, если система требует разработки, предполагаемые библиотеки для разработки (перечисление);
  * оборудование, необходимое для реализации системы (перечисление);
  * какая информация на входе (какую информацию система получает для обработки);
  * какая информация на выходе (какую информацию система может предоставить в результате работы и кому).
=== 2.2. Описание бизнес-процессов ===

При составлении ТЗ также необходимо создать понятное визуальное представление для исполнителей. Бизнес-процессы должны включать в себя следующие условия:
  * в процессах (или описаниях к ним) должны быть пометки – все участники должны быть учтены и прямо указаны их обязанности;
  * процессы должны быть полными и законченными, представлены все процессы, которые должны быть для создания продукта;
  * процессы должны быть представлены в графическом виде;
  * следует использовать общепринятые термины и правила, для чистоты и понятности схемы.
=== 2.3. Описание данных ===

Составить перечень данных, которые участвуют в функционировании системы:
  * хранятся внутри системы;
  * получаются от внешних участников;
  * обрабатываются системой;
  * передаются внешним участникам.
Следует описывать в виде таблицы со следующими колонками: тип данных – форма представления – источник получения – хранение – обработка – передача.
==== 3.	Назначение разработки ====

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

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

Возможные требования:
  * доступность;
  * отказоустойчивость;
  * требования, связанные с особенностями данных – по типу, объему, способу хранения, скорости передачи.
Ограничения могут быть связаны также с особенностями данных и процессов, например, какие-то данные могут быть актуальны или получаемы только в какой-то конкретный промежуток времени и так далее.
Также в этом разделе указывается размер и особенности технологических окон для обслуживания системы (например, для обновления, для бэкапов и так далее).
==== 5.	Требования к документации ====

Должен быть указан предварительный состав программной документации и, при необходимости, специальные требования к ней
Следует указать должностные инструкции – в этом разделе необходимо перечислить весь штатный персонал проекта и их обязанности соответственно.
==== 6.	Технико-экономические показатели ====

Должны быть указаны: ориентировочная экономическая эффективность, предполагаемая годовая потребность.
==== 7.	Стадии и этапы разработки ====

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

Должны быть указаны виды испытаний и общие требования к приемке работы.
Должны быть перечислены какие конкретно регламенты проверки и каких конкретно систем должны быть написаны. Учитывайте, что должны быть и регламенты действия в аварийных ситуациях.
Опишите, какие тестовые системы должны быть внутри проекта:
  * название;
  * какой проект она тестирует;
  * какие технические средства нужны для ее реализации, это какие-то готовые программные продукты или создаются свои – надо указать;
  * формат результата работы тестовой системы (кто оповещается, каким образом, с каким интервалом).
===== 4. Требования к безопасности =====


В требования по безопасности включают требования по обеспечению целостности и конфиденциальности при передачи, получении и обработке данных.
Ключевые требования к решению для обеспечения безопасности Интернета вещей перечислены ниже.
  * Легкость решения: любое предложение по обеспечению безопасности интернета вещей должно учитывать ограниченность ресурсов и поддерживать легкие решения. Облегченные решения для обеспечения безопасности должны обеспечивать баланс между используемыми криптографическими методами и энергоэффективностью.
  * По возможности – использовать сквозное шифрование при обмене данными. Данный способ шифрования может быть реализован как при передаче данных через XMPP, так и через MQTT.
  * Обеспечить возможность серверу принимать информацию только от идентифицированных устройств. Данное требование позволит сильно ограничить круг потенциальных угроз для сервера Интернета Вещей.
  * Пользователи продукта компании должны иметь возможность достаточно детально настраивать приватность своей учетной записи.
  * Необходимо обеспечить возможность легкого и быстрого масштабирования. Интернет Вещей может включать в себя множество устройств и компания должна обеспечить возможность принять высокую нагрузку на свои сервера.
  * Решение должно иметь возможность собирать статистику по ошибкам и частоте сбоев.
  * По возможности для обмена использовать протоколы XMPP или MQTT.
  * На сервере должна быть реализована возможность отслеживания нетипичного поведения устройств.
  * По возможности устройство должно иметь возможность хранить и периодически обновлять закрытый ключ, который можно использовать для аутентификации или авторизации.
===== 5. Перечень рекомендованного программного обеспечения =====

Ниже представлен список рекомендованного при разработке сервисов программного обеспечения.
  * Ejabberd как сервер для XMPP или MQTT.
  * ОС для функционирования серверного решения – ALT Linux Server P10.
  * Виртуальная машина для настройки Ejabberd – Proxmox VE.
  * При необходимости использования сторонних программных продуктов – необходимо использование библиотек, модулей и продуктов с открытым исходным кодом в соответствии с их лицензиями.