Гибкое моделирование

Гибкое моделирование ( AM ) — это методология моделирования и документирования программных систем, основанная на лучших практиках. Это набор ценностей и принципов, которые можно применить в проекте разработки (гибкого) программного обеспечения. Эта методология более гибкая, чем традиционные методы моделирования, что делает ее более подходящей для быстро меняющейся среды. ^[1] Это часть набора инструментов гибкой разработки программного обеспечения .

Гибкое моделирование является дополнением к другим гибким методологиям разработки , таким как Scrum , экстремальное программирование (XP) и Rational Unified Process (RUP). Он явно включен в структуру дисциплинированной гибкой доставки (DAD). По статистике 2011 года, гибкое моделирование составляло 1% от всей гибкой разработки программного обеспечения. ^[2]

Гибкое моделирование — это одна из форм гибкого проектирования на основе моделей (Agile MDE), которая была принята в нескольких областях применения, таких как разработка веб-приложений, финансы и автомобильные системы. ^[3]

Основные практики

Существует несколько основных практик:

Документация

Документируйте постоянно. Документация ведется на протяжении всего жизненного цикла, параллельно с созданием остальной части решения.
Документ опоздал. Документация составляется как можно позже, избегая спекулятивных идей, которые могут измениться в пользу стабильной информации.
Исполняемые характеристики. Требования задаются в виде исполняемых «заказных тестов», а не неисполняемой «статической» документации.
Информация из одного источника. Информация (модели, документация, программное обеспечение) хранится в одном и только одном месте, чтобы избежать вопросов о том, какая версия/информация является «правильной».

Моделирование

Активное участие заинтересованных сторон. Заинтересованные стороны моделируемого решения/программного обеспечения должны активно участвовать в этом. Это расширение практики выездного обслуживания клиентов от Extreme Programming .
Архитектурное видение. В начале программного проекта команда выполняет легкое высокоуровневое моделирование, едва ли достаточно хорошее (JBGE), чтобы изучить архитектурную стратегию, которая, по мнению команды, будет работать.
Инклюзивные инструменты. Отдавайте предпочтение инструментам моделирования, таким как доски и бумага, с которыми легко работать (они входят в комплект поставки).
Итерационное моделирование. Если требование/элемент работы не было достаточно подробно изучено с помощью прогнозного моделирования, команда может решить провести такое исследование во время сеанса планирования итерации/спринта. Необходимость сделать это обычно рассматривается как признак того, что команда не проводит достаточного прогнозного моделирования.
Едва достаточно хорошо (JBGE). Всех артефактов, включая модели и документы, должно быть достаточно для выполнения поставленной задачи. JBGE является контекстуальным по своей природе, в случае модели он определяется сочетанием сложности того, что описывает модель, и навыков аудитории для этой модели.
Прогнозное моделирование. Agile-команда просматривает свое отставание на одну или несколько итераций/спринтов вперед, чтобы убедиться, что требование/рабочий элемент готов к работе. это также называется «уборкой невыполненной работы» или «уточнением невыполненной работы» В Scrum .
Модельный штурм. Короткий, часто импровизированный сеанс гибкого моделирования. Сеансы модельного штурма проводятся для изучения деталей требований или аспектов вашего дизайна.
Несколько моделей. Разработчики гибкого моделирования должны знать, как создавать различные типы моделей (например, пользовательские истории, карты-истории, модели данных, диаграммы Unified Modeling Language (UML) и т. д.), чтобы применять лучшую модель для конкретной ситуации.
Приоритетные требования. Требования следует прорабатывать в приоритетном порядке.
Предвидение требований. В начале программного проекта команда выполняет легкое высокоуровневое моделирование в формате JBGE для изучения требований заинтересованных сторон.

Ограничения

Существует значительная зависимость от личного общения и сотрудничества с клиентами. Дисциплины гибкого моделирования могут быть трудными для применения. ^{[ нужна ссылка ]}:

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

См. также

Ссылки

^ Домашняя страница гибкого моделирования (AM), эффективные методы моделирования и документации.
^ «Результаты исследования состояния гибкой разработки, 2011 г.» . Архивировано из оригинала 17 июля 2015 г. Проверено 26 июня 2014 г.
^ Альфрайхи, Хесса Абдулрахман А.; Лано, Кевин Чарльз (январь 2017 г.). «Интеграция гибкой разработки и разработки на основе моделей: систематический обзор литературы» . 5-я Международная конференция по модельно-ориентированной инженерии и разработке программного обеспечения : 451–458. дои : 10.5220/0006207004510458 . ISBN 978-989-758-210-3 . S2CID 11369604 .

Внешние ссылки

[1] Домашняя страница гибкого моделирования (AM), эффективные методы моделирования и документации.

[2] «Результаты исследования состояния гибкой разработки, 2011 г.» . Архивировано из оригинала 17 июля 2015 г. Проверено 26 июня 2014 г.

[3] Альфрайхи, Хесса Абдулрахман А.; Лано, Кевин Чарльз (январь 2017 г.). «Интеграция гибкой разработки и разработки на основе моделей: систематический обзор литературы» . 5-я Международная конференция по модельно-ориентированной инженерии и разработке программного обеспечения : 451–458. дои : 10.5220/0006207004510458 . ISBN 978-989-758-210-3 . S2CID 11369604 .

[1]

[2]

[3]