Различия

Показаны различия между двумя версиями страницы.

--- sharix:iot_recommendations [2022/08/02 17:42] – создано sharixadmin
+++ sharix:iot_recommendations [2022/09/11 21:48] (текущий) – удалено sharixadmin
@@ Строка 1: / Строка 1: @@
-====== Рекомендации по подготовке технического задания для разработки сервисов на основе Интернета Вещей ======
-===== 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.
-  * При необходимости использования сторонних программных продуктов – необходимо использование библиотек, модулей и продуктов с открытым исходным кодом в соответствии с их лицензиями.