2. Терминология
• Embedded (встроенная) система - продукт из множества
программных и аппаратных подсистем
• IoT (интернет вещей) - сеть объектов, измеряющих
параметры состояния (собственного или окружающей
среды), использующих и передающих эту информацию
4. План доклада
В кадре:
• Особенности IoT/Embedded проектов с точки зрения
аналитика
• Примеры полезных техник моделирования
За кадром:
• Анализ данных
• Системы, от которых зависят жизни людей
6. Особенность 1: терминология
Краткое описание проекта:
Develop a BLE-enabled PCB to be installed inside an MVP GO
console. iOS app to support general functions, as well as bond
and RTC management for admins.
7. Особенность 1: терминология
Расшифровки сокращений/терминов из примера:
• BLE - Bluetooth 4.0 низкого энергопотребления
• PCB - печатная плата
• GO - Garage Opener, название проекта (жаргон проекта)
• RTC - часы реального времени, компонента
• Bond - сертификаты, хранящиеся на устройстве для
соединения с другим известным устройством по BLE
(жаргон проекта)
8. Особенность 2: взаимодействие между
разработчиками различных специализаций
Команда проекта:
• Руководитель проекта
• Бизнес-аналитик
• Инженер-схемотехник
• Разработчик встроенных систем
• Тестировщик
• Дизайнер интерфейсов
• iOS-разработчик
9. Особенность 3: цена изменений
• Изменять встроенное ПО – сложно
• Изменять оборудование – еще сложнее
10. Особенность 4: особые ограничения
• Физические: размер, форма, вес, материалы,
устойчивость к химикатам, ударопрочность
• Производственные ограничения: сроки, стоимость,
стандарты производителя
• Уже выбранные компоненты, технологии
• Протоколы передачи данных
11. Особенность 5: нефункциональные
требования
• Производительность
• Эффективность
• Надежность и доступность
• Устойчивость
• Компьютерная безопасность
• Безопасность эксплуатации
• Удобство использования
• Стандарты и сертификация
12. Устойчивость - пример
«При отказе встроенных в печатную плату модулей
(память, BLE) система должна сообщать о сбое
пользователю путем световой индикации, сохраняя при
этом основные функции»
13. Компьютерная безопасность - пример
«Система не должна подключаться к сети интернет; все
данные должны храниться только на панели управления
дверями гаража и на смартфоне»
14. Безопасность эксплуатации - пример
• «Если согласно показаниям ИК-датчиков под дверью есть
препятствие, система не должна позволять двери двигаться
вниз»
• «Система должна предоставлять возможность открыть
дверь гаража изнутри вне зависимости от состояния
устройства»
18. Техника 1: архитектурные диаграммы
Помогают:
• Проверить совпадение общего понимания системы у
команды
• Обозначить границы проекта
• Наиболее верно назначить функции компонентам системы
• Обнаружить и уточнить пропущенные требования
19. Техника 2: диаграммы состояний
Помогают:
• Емко описывать сложное поведение системы
• Обнаружить и уточнить пропущенные требования
21. Другие техники
• Блок-схемы
• Use cases
• Глоссарий
• Словарь данных (data dictionary)
• Прототипы пользовательского интерфейса
• Бизнес-правила
• …
Все стандартные аналитические подходы применимы!
22. Итоги
• Аналитики на IoT/embedded проектах нужны
• У этих проектов есть свои особенности
• Терминология
• Новые роли в команде
• Цена изменений
• Ограничения
• Нефункциональные требования
• Можно и нужно применять стандартные техники
23. Рекомендуемая литература
• Karl Wiegers - Software requirements (3rd edition, Ch. 26)
• Phillip Koopman - Better embedded systems software
• IEEE 1233-1998 (IEEE Guide for Developing System
Requirements Specifications - SyRS)
Добавить disclaimer про субъективность взглядов на особенности??
куча новой терминологии и аббревиатур (в каком-то смысле - это как новая предметная область: приходит к тебе новый проект, а там один абзац описания с кучей непонятных терминов: <пример?? FCC compliance OOC.>. пример про "разницу" BLE и Bluetooth)
куча новой терминологии и аббревиатур (в каком-то смысле - это как новая предметная область: приходит к тебе новый проект, а там один абзац описания с кучей непонятных терминов: <пример?? FCC compliance OOC.>. пример про "разницу" BLE и Bluetooth)
многие вещи, которые легко сделать в обычном софте, оказываются очень трудозатратными в embedded-разработке. <?>и в общем - легче вносить изменения в soft, чем в hardware/firmware</?> (пример с изменением имени сущности)
<?>более тесная связь с этапом дизайна</?> (пример с системой слежения за детьми - без гэйтвэя, с гейтвэем - <c>или это привести как пример диаграммы?</c>)
<?>очень распространенный тип проектов - доработка уже существующих устройств, что накладывает доп.ограничения на всю команду, в т.ч. аналитика</?>
особые типы нефункциональных требований
Очевидно, что к каждой конкретной системе будет применима только часть из них
?? А что применимо к моей??
? Нужен ли какой-то слайд-вступление перед техниками?
? Нужен ли какой-то слайд-вступление перед техниками?
<?>+event/response table?</?>
<?>+event/response table?</?>
(юзкейсы, глоссарий, data dictionary, ) - все применимо. <?>в т.ч. и для того, чтобы прослеживать требования к реализации (пример с "золочением" продукта, несмотря на это, что это должен быть быть MVP)</?>
Все стандартные аналитические подходы применимы – с небольшими корректировками
* Koopman: не стоит пугаться того, что во вступлении книга рекомендуется людям с опытом работы на embedded-проектах - на самом деле она пойдет и людям, которые интересуются такими проектами, имея опыт в других ИТ-областях
IEEE: различие между документами SyRS (спецификация требований к системе) и SRS (спецификация требований к программному обеспечению)
?? Добавить статьи про UML?