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

Эта статья поднимает множество проблем. Пожалуйста помоги Улучши это или обсудите эти вопросы на страница обсуждения. (Узнайте, как и когда удалить эти сообщения-шаблоны) Тема этой статьи может не соответствовать Википедии общее руководство по известности. Пожалуйста, помогите установить известность, указав надежные вторичные источники которые независимый темы и обеспечить ее подробное освещение, помимо банального упоминания. Если известность не может быть установлена, статья, вероятно, будет слился, перенаправлен, или же удалено. Найдите источники: «Гибкое моделирование»  – Новости  · газеты  · книги  · ученый  · JSTOR (Ноябрь 2019) (Узнайте, как и когда удалить этот шаблон сообщения) Похоже, что один из основных авторов этой статьи тесная связь со своим предметом. Может потребоваться очистка для соответствия политике содержания Википедии, в частности нейтральная точка зрения. Пожалуйста, обсудите подробнее страница обсуждения. (Ноябрь 2019) (Узнайте, как и когда удалить этот шаблон сообщения) Эта статья может чрезмерно полагаться на источники слишком тесно связан с предметом, потенциально препятствуя публикации статьи проверяемый и нейтральный. Пожалуйста помоги Улучши это заменив их более подходящими цитаты к надежные, независимые сторонние источники. (Ноябрь 2019) (Узнайте, как и когда удалить этот шаблон сообщения) (Узнайте, как и когда удалить этот шаблон сообщения)

Гибкое моделирование (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 или больше) без адекватной инструментальной поддержки
• Когда члены команды не могут делиться моделями и сотрудничать с ними (что может гибкая разработка программного обеспечения в общем сложно)
• Когда навыки моделирования слабые или отсутствуют.

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

• Сюжетное моделирование
• Гибкая разработка программного обеспечения
• Диаграмма устойчивости

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

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

• Домашняя страница Agile Modeling
• Разработка на основе гибких моделей (AMDD)