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

Agile modeling

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

Agile-моделирование - это дополнение к другим гибкое развитие такие методологии, как Scrum, экстремальное программирование (XP) и рациональный унифицированный процесс (RUP). Он явно включен как часть дисциплинированная гибкая доставка (DAD) фреймворк. Согласно статистике за 2011 год, на гибкое моделирование приходилось 1% всех гибких разработок программного обеспечения.[2]

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

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

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

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

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

  1. Активное участие заинтересованных сторон. Заинтересованные стороны моделируемого решения / программного обеспечения должны активно участвовать в этом. Это расширение практики работы с клиентами на местах от Экстремальное программирование.
  2. Представление архитектуры. Команда выполняет легковесное высокоуровневое моделирование, которого едва ли достаточно (JBGE) в начале программного проекта, чтобы изучить стратегию архитектуры, которая, по мнению группы, будет работать.
  3. Инклюзивные инструменты. Предпочитайте инструменты моделирования, такие как белые доски и бумага, с которыми легко работать (они включены).
  4. Итерационное моделирование. Когда требование / рабочий элемент не были достаточно подробно изучены с помощью прогнозного моделирования, команда может решить провести это исследование во время сеанса планирования итерации / спринта. Необходимость сделать это обычно рассматривается как симптом того, что команда не выполняет достаточного прогнозного моделирования.
  5. Едва достаточно (JBGE). Все артефакты, включая модели и документы, должны быть достаточными для решения поставленной задачи. JBGE носит контекстный характер, в случае модели он определяется сочетанием сложности того, что модель описывает, и навыков аудитории для этой модели.
  6. Прогнозное моделирование. Agile-команда просматривает свой бэклог на одну или несколько итераций / спринтов вперед, чтобы убедиться, что требование / рабочий элемент готовы к работе. Также называется «очисткой невыполненных работ» или «уточнением невыполненных работ» в Scrum.
  7. Модель штурма. Короткий, часто импровизированный сеанс гибкого моделирования. Сеансы штурма моделей проводятся для изучения деталей требований или аспектов вашего дизайна.
  8. Несколько моделей. Разработчики Agile-моделей должны знать, как создавать различные типы моделей (например, пользовательские истории, карты-истории, модели данных, Единый язык моделирования (UML) диаграмм и др.), Чтобы применить лучшую модель для конкретной ситуации.
  9. Приоритетные требования. Требования следует обрабатывать в приоритетном порядке.
  10. Разработка требований. Команда выполняет легкое высокоуровневое моделирование, которое является JBGE в начале проекта программного обеспечения, чтобы изучить требования заинтересованных сторон.

Ограничения

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

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

Смотрите также

Рекомендации

  1. ^ Домашняя страница Agile-моделирования (AM), эффективные методы моделирования и документация
  2. ^ Результаты исследования состояния гибкой разработки, 2011 г.

внешняя ссылка