Анализ требований в IoT/Embedded проектах
•Download as PPTX, PDF•
1 like•917 views
Доклад Юлии Селявко на конференции Analyst Days-5, 22-23 апреля 2016 г., Санкт-Петербург www.analystdays.com
Recommended
Recommended
More Related Content
Viewers also liked
Viewers also liked (15)
More from SQALab
More from SQALab (20)
Анализ требований в IoT/Embedded проектах
- 1. Анализ требований в IoT/Embedded проектах Юлия Селявко HiQo Solutions, Минск
- 2. Терминология • Embedded (встроенная) система - продукт из множества программных и аппаратных подсистем • IoT (интернет вещей) - сеть объектов, измеряющих параметры состояния (собственного или окружающей среды), использующих и передающих эту информацию
- 3. Актуальность
- 4. План доклада В кадре: • Особенности IoT/Embedded проектов с точки зрения аналитика • Примеры полезных техник моделирования За кадром: • Анализ данных • Системы, от которых зависят жизни людей
- 5. Проект: система открытия дверей гаража
- 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. Безопасность эксплуатации - пример • «Если согласно показаниям ИК-датчиков под дверью есть препятствие, система не должна позволять двери двигаться вниз» • «Система должна предоставлять возможность открыть дверь гаража изнутри вне зависимости от состояния устройства»
- 15. Техника 1: архитектурные диаграммы
- 16. Техника 1: архитектурные диаграммы
- 17. Техника 1: архитектурные диаграммы
- 18. Техника 1: архитектурные диаграммы Помогают: • Проверить совпадение общего понимания системы у команды • Обозначить границы проекта • Наиболее верно назначить функции компонентам системы • Обнаружить и уточнить пропущенные требования
- 19. Техника 2: диаграммы состояний Помогают: • Емко описывать сложное поведение системы • Обнаружить и уточнить пропущенные требования
- 20. Техника 2: диаграмма состояний *упрощенная нотация (не UML State Machine)
- 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)
- 24. Спасибо за внимание! Вопросы? Юлия Селявко HiQo Solutions julia.seliavko@hiqo-solutions.com
Editor's Notes
- Добавить 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?